Эту книгу хорошо дополняют:

Лидеры продукта

Ричард Бэнфилд, Мартин Эрикссон, Нейт Уокингшо

Deadline

Том Демарко

Scrum

Джефф Сазерленд

Управление продуктом в Scrum

Роман Пихлер

MARTY CAGAN
Founder, Silicon Valley Product Group

INSPIRED:

HOW TO CREATE TECH PRODUCTS CUSTOMERS LOVE

Second Edition

WILEY

МАРТИ КАГАН

ВДОХНОВЛЕННЫЕ

ВСЕ, ЧТО НУЖНО ЗНАТЬ ПРОДАКТ-МЕНЕДЖЕРУ

МОСКВА
«МАНН, ИВАНОВ И ФЕРБЕР»
2020

Информация
от издательства

Научные редакторы Андрей Аликимович, Марьяна Онысько

Издано с разрешения John Wiley & Sons International Rights, Inc. и литературного агентства Александра Корженевского

На русском языке публикуется впервые

Книга рекомендована к изданию Константином Плескачем, Аленой Китабовой, Наталией Юлдашевой, Ильей Сидоренко, Павлом Моисеевым, Ольгой Дормидонтовой, Вячеславом Молодых, Константином Валиотти, Евгением Коноваловым

Каган, Марти

Вдохновленные. Все, что нужно знать продакт-менеджеру / Марти Каган ; пер. с англ. Н. Яцюк ; [науч. ред. А. Аликимович, М. Онысько]. — М. : Манн, Иванов и Фербер, 2020.

ISBN 978-5-00146-431-0

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

Книга будет полезна инвесторам, продакт-менеджерам, маркетологам, разработчикам, стартаперам.

Все права защищены.

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

© Wiley, 2018
All Rights Reserved. This translation published under license with the original publisher John Wiley & Sons, Inc.

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2020

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

Аманда Ричардсон, директор по стратегическому развитию и управлению данными HotelTonight

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

Таня Кордри, бывший директор по цифровым технологиям Guardian News & Media

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

Тереза Торрес, коуч по исследованию продукта

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

Гарри Неллис, партнер Accel

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

Сара Роуз, лидер продукта и операционный директор

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

Марти Эбботт, СЕО AKF Partners, бывший технический директор eBay

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

Шриприя Махеш, партнер Omidyar Network

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

Фил Терри, основатель и СЕО Collaborative Gain, соавтор книги Customers Included

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

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

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

Джейсон Ли, СЕО и основатель компании Boolan, Шанхай

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

Джефф Тром, основатель и технический директор Workiva

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

Одри Крейн, партнер DesignMap

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

Шон Бойер, основатель Snagajob and goHappy

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

Мария Томас, член совета директоров и инвестор

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

Пьюнит Сони, основатель и CEO Robin, бывший менеджер по продажам Google

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

Петра Вилле, коуч в области исследования продукта

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

Чак Гейгер, технический директор и директор по продуктам Chegg

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

Хоуп Гурион, лидер продукта

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

Майк Фишер, технический директор Etsy

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

Эрин Штадлер, коуч в области исследования продукта, Boomtown Accelerator

Эта книга посвящается моему отцу Карлу Кагану. В 1969 году он стал первым кандидатом компьютерных наук в США (до этого информатика и другие компьютерные науки входили в учебные программы по электротехнике) и написал первую книгу о базах данных (Data Management Systems вышла в 1973 году, тоже в издательстве John Wiley & Sons).

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

ПРЕДИСЛОВИЕ

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

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

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

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

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

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

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

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

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

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

ЧАСТЬ I

УРОКИ ЛУЧШИХ ТЕХНОЛОГИЧЕСКИХ КОМПАНИЙ

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

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

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

Только вот проблема: продукт никто не покупал.

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

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

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

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

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

За следующие тридцать лет мне посчастливилось поработать над некоторыми самыми успешными высокотехнологичными продуктами современности. Я работал в HP на заре эры персональных компьютеров; в Netscape Communications — во время появления интернета (вице-президентом по платформам и инструментам); в eBay — в период становления электронной торговли и электронных рынков (сначала старшим вице-президентом по продуктам и проектированию, а затем в качестве консультанта по вопросам стартапов сотрудничал со многими из тех, кто сегодня добился огромного успеха в сфере выпуска высокотехнологичных продуктов).

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

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

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

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

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

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

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

ГЛАВА 1

КТО СТОИТ ЗА КАЖДЫМ ОТЛИЧНЫМ ПРОДУКТОМ

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

Обычно такого человека называют менеджером продукта, но он может быть соучредителем стартапа или СЕО3. Бывает также, что он играет в своей команде другую роль, а на первый план вышел потому, что сумел уловить подлинную потребность рынка (и своей компании).

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

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

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

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

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

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

ГЛАВА 2

ВЫСОКОТЕХНОЛОГИЧНЫЕ ПРОДУКТЫ И СЕРВИСЫ

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

Конечно, кое-что из того, о чем мы с вами поговорим далее, пригодится и тем, кто занимается другими видами продуктов, но в этом случае я никаких гарантий не даю. Да и, честно говоря, менеджерам большинства нетехнологичных продуктов, таких как товары широкого потребления, и так доступны отличные источники знаний. Я же сосредоточился на уникальных проблемах и вызовах исключительно высокотехнологичных продуктов и сервисов. Если точнее, мы будем говорить о таких продуктах, как интернет-магазины или маркетплейсы (например, Netflix, Airbnb, Etsy), социальные сети (Facebook, LinkedIn, Twitter), бизнес-сервисы (Salesforce.com, Workday, Workiva), устройства (Apple, Sonos, Tesla) и мобильные приложения (Uber, Audible, Instagram).

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

ГЛАВА 3

СТАРТАПЫ: КАК ДОСТИЧЬ СООТВЕТСТВИЯ «ПРОДУКТ — РЫНОК»

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

В целом я определяю стартап как компанию, которая очень молода и ее продукт пока еще не соответствует ожиданиям рынка. Соответствие «продукт — рынок» (product-market fit) — чрезвычайно важная концепция; далее мы дадим ее определение, а пока просто заметим, что стартап — это компания, которая еще только пытается придумать продукт, способный положить начало жизнеспособному бизнесу.

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

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

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

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

ГЛАВА 4

КОМПАНИИ НА СТАДИИ РОСТА: УСПЕШНОЕ МАСШТАБИРОВАНИЕ

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

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

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

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

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

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

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

ГЛАВА 5

КОРПОРАЦИИ: НЕПРЕРЫВНЫЕ ПРОДУКТОВЫЕ ИННОВАЦИИ

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

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

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

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

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

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

А еще в компании постоянно ведутся разговоры о том, как же так получается, что такие крупные корпорации, как Adobe, Amazon, Apple, Facebook, Google и Netflix, смогли избежать этой печальной участи. Руководство ломает голову над вопросом, почему же им не удается сделать то же самое. Но факт остается фактом: они смогли. И чтобы и мы смогли, нужно внести серьезные изменения, о которых и рассказывается в этой книге.

ГЛАВА 6

ФУНДАМЕНТАЛЬНЫЕ ПРИЧИНЫ НЕУДАЧ В РАБОТЕ НАД ПРОДУКТОМ

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

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

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

Рис. 6.1. Основные этапы создания продукта

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

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

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

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

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

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

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

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

Хорошо, пусть большинство команд работают так, но почему это обязательно становится причиной стольких проблем? Давайте-ка расставим все точки над «и» прямо сейчас, чтобы ясно понять, почему этот распространенный повсеместно метод приводит к неудачам при создании софта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГЛАВА 7

LEAN И AGILE И НЕ ТОЛЬКО

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

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

Но, как я уже сказал, их тоже нельзя считать волшебными средствами, и, как и в случае с любым инструментом, нужно подходить к их использованию с умом. Множество команд утверждают, что придерживаются принципов Lean, а сами месяцами работают над тем, что называют «минимально жизнеспособным продуктом» (minimum viable product, MVP). На самом деле они не знают, что у них получилось и будет ли это продаваться, до тех пор, пока не потратят массу времени и денег. Вряд ли такая стратегия в духе Lean. Или же они бросаются в другую крайность: считают, что должны тестировать и перепроверять каждую мелочь, и, соответственно, не слишком быстро продвигаются вперед.

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

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

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

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

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

Как вы скоро убедитесь, книга посвящена именно этим трем принципам.

ГЛАВА 8

КЛЮЧЕВЫЕ ИДЕИ

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

ПРОДУКТ В ЦЕЛОМ

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

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

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

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

НЕПРЕРЫВНОЕ ИССЛЕДОВАНИЕ И ВЫВЕДЕНИЕ ПРОДУКТА НА РЫНОК

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

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

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

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

Рис. 8.1. Непрерывный процесс исследования продукта и его поставки на рынок

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

ИССЛЕДОВАНИЕ ПРОДУКТА

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

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

Будет ли пользователь это покупать (или использовать)?

Сможет ли он понять, как это использовать?

Смогут ли инженеры это построить?

Станут ли заинтересованные стороны это поддерживать?

ПРОТОТИПИРОВАНИЕ

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

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

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

ПОСТАВКА ПРОДУКТА НА РЫНОК

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

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

СООТВЕТСТВИЕ ПРОДУКТА ОЖИДАНИЯМ РЫНКА

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

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

ВИДЕНИЕ ПРОДУКТА

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

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

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

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

Минимально жизнеспособный продукт

Минимально жизнеспособный продукт (minimum viable product, MVP)4 — одна из самых важных концепций в нашей отрасли, предложенная много лет назад. Термин придумал Фрэнк Робинсон (в 2001 году), а я писал об этой концепции в первом издании книги (в 2008 году). Но заслуга ее популяризации принадлежит Эрику Рису, в частности его работе The Lean Startup5 (2011 года).

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

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

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

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

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

ЧАСТЬ II

ПРАВИЛЬНЫЕ ЛЮДИ

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

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

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

ПРОДУКТОВЫЕ КОМАНДЫ

ОБЗОР

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

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

ГЛАВА 9

ПРИНЦИПЫ СИЛЬНЫХ ПРОДУКТОВЫХ КОМАНД

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

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

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

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

КОМАНДА «МИССИОНЕРОВ»

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

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

СОСТАВ КОМАНДЫ

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

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

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

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

ПОЛНОМОЧИЯ И ОТВЕТСТВЕННОСТЬ В КОМАНДЕ

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

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

РАЗМЕР КОМАНДЫ

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

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

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

ПОДОТЧЕТНОСТЬ В ПРОДУКТОВОЙ КОМАНДЕ

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

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

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

СОТРУДНИЧЕСТВО В КОМАНДЕ

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

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

РАСПОЛОЖЕНИЕ КОМАНДЫ

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

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

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

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

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

ЗАДАЧИ И КОМПЕТЕНЦИИ КОМАНДЫ

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

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

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

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

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

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

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

ВРЕМЯ РАБОТЫ КОМАНДЫ

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

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

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

САМОСТОЯТЕЛЬНОСТЬ КОМАНДЫ

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

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

ПОЧЕМУ ЭТО РАБОТАЕТ

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

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

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

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

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

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

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

Принципы и методики

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

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

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

ГЛАВА 10

МЕНЕДЖЕР ПРОДУКТА

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

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

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

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

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

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

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

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

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

КРУГ ОБЯЗАННОСТЕЙ

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

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

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

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

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

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

ДОСКОНАЛЬНОЕ ЗНАНИЕ ПОТРЕБИТЕЛЯ

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

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

ГЛУБОКОЕ ПОГРУЖЕНИЕ В ДАННЫЕ

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

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

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

ДОСКОНАЛЬНОЕ ЗНАНИЕ БИЗНЕСА

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

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

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

ДОСКОНАЛЬНОЕ ЗНАНИЕ РЫНКА И ОТРАСЛИ

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

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

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

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

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

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

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

УМНЫЙ, КРЕАТИВНЫЙ И НАСТОЙЧИВЫЙ

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

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

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

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

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

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

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

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

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

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

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

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

ЗНАКОМЬТЕСЬ С ЛУЧШИМИ ПРОДАКТ-МЕНЕДЖЕРАМИ

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

Джейн Мэннинг из Google.

Лиа Хикман из Adobe.

Алекс Прессланд из BBC.

Мартина Лаученгко из Microsoft.

Кейт Арнольд из Netflix.

Камилла Херст из Apple.

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

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

Вот главные уроки, которые вы, я надеюсь, из этого вынесете:

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

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

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

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

Чем менеджер продукта отличается от владельца продукта

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

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

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

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

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

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

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

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

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

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

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

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

ГЛАВА 11

ДИЗАЙНЕР ПРОДУКТА

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

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

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

ИССЛЕДОВАНИЕ ПРОДУКТА

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

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

КОМПЛЕКСНЫЙ ОПЫТ ВЗАИМОДЕЙСТВИЯ

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

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

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

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

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

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

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

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

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

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

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

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

ПРОТОТИПИРОВАНИЕ

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

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

ТЕСТИРОВАНИЕ КЛИЕНТСКОГО ОПЫТА

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

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

ДИЗАЙН ВЗАИМОДЕЙСТВИЯ И ГРАФИЧЕСКИЙ ДИЗАЙН

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

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

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

КОГДА ДИЗАЙН ПРОДУКТА ОТСУТСТВУЕТ

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

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

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

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

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

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

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

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

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

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

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

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

Сделайте все от вас зависящее, чтобы дизайнер сидел рядом с вами.

Включайте дизайнера в дело с самого начала разработки идеи.

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

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

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

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

ГЛАВА 12

ИНЖЕНЕРЫ-ПРОГРАММИСТЫ

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

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

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

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

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

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

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

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

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

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

Роль технического руководителя

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

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

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

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

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

ГЛАВА 13

ПРОДУКТОВЫЙ МАРКЕТОЛОГ

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

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

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

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

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

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

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

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

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

ГЛАВА 14

ВСПОМОГАТЕЛЬНЫЕ РОЛИ

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

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

ИССЛЕДОВАТЕЛИ ПОЛЬЗОВАТЕЛЕЙ

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

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

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

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

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

АНАЛИТИКИ ДАННЫХ

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

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

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

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

ИНЖЕНЕРЫ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

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

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

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

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

ГЛАВА 15

ЗНАКОМЬТЕСЬ: ДЖЕЙН МЭННИНГ ИЗ GOOGLE

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

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

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

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

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

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

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

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

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

МАСШТАБИРОВАНИЕ: ПЕРСОНАЛ

ОБЗОР

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

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

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

ГЛАВА 16

РОЛЬ РУКОВОДСТВА

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

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

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

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

ЛИДЕРСТВО В УПРАВЛЕНИИ ПРОДУКТОМ

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

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

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

ЛИДЕРСТВО В СФЕРЕ ДИЗАЙНА ПРОДУКТА

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

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

ЛИДЕРСТВО В ТЕХНОЛОГИЧЕСКОЙ СФЕРЕ

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

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

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

ЦЕЛОСТНЫЙ ВЗГЛЯД НА РУКОВОДЯЩИЕ РОЛИ

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

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

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

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

ГЛАВА 17

ДИРЕКТОР ПО ПРОДУКТУ

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

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

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

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

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

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

ПРОФЕССИОНАЛЬНЫЕ КАЧЕСТВА

Если говорить предметно, то вы ищете человека с доказанной компетентностью в четырех ключевых аспектах: 1) развитие команды; 2) видение продукта; 3) исполнительность; 4) продуктовая культура.

РАЗВИТИЕ КОМАНДЫ

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

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

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

ВИДЕНИЕ ПРОДУКТА И СТРАТЕГИЯ ЕГО РАЗВИТИЯ

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

В компании есть СЕО или основатель, имеющий максимально четкое видение продукта.

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

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

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

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

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

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

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

ИСПОЛНИТЕЛЬНОСТЬ

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

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

ПРОДУКТОВАЯ КУЛЬТУРА

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

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

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

ОПЫТ

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

ВЗАИМОПОНИМАНИЕ

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

Менеджер продуктовой группы

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

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

Традиционно менеджеры продукта проходят один из двух путей карьерного роста.

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

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

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

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

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

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

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

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

ГЛАВА 18

ДИРЕКТОР ПО ТЕХНОЛОГИЯМ

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

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

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

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

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

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

ОРГАНИЗАЦИЯ

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

РУКОВОДСТВО

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

ПОСТАВКА НА РЫНОК

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

АРХИТЕКТУРА

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

ИССЛЕДОВАНИЕ ПРОДУКТА

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

ЕВАНГЕЛИЗМ

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

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

ГЛАВА 19

ОПЕРАЦИОННЫЙ МЕНЕДЖЕР С ТЕХНИЧЕСКИМИ НАВЫКАМИ

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

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

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

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

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

ГЛАВА 20

СТРУКТУРИРОВАНИЕ ПРОДУКТОВЫХ КОМАНД

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

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

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

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

Согласованность с инвестиционной стратегией.

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

Минимизация взаимозависимости.

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

Чувство владельца и самоуправление.

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

Максимальная оптимизация.

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

Видение продукта и стратегия его развития.

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

Размер команды.

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

Согласованность с архитектурой.

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

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

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

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

Разделение по пользователю или клиенту.

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

Разделение по бизнес-подразделениям.

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

Структура — цель движущаяся.

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

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

Масштабирование самоуправления

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

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

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

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

Команда хочет изменить то, что, по мнению руководства, является частью фундамента компании.

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

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

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

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

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

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

Уровень командного мастерства

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

Значение скорости

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

Значение интеграции

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

Источник инноваций

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

Размер и расположение компании

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

Культура компании

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

Зрелость технологии

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

Значение для бизнеса

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

Уровень ответственности

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

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

Бизнес-контекст включает в себя два основных элемента:

Общее видение продукта.

Конкретные бизнес-цели, стоящие перед каждой командой.

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

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

ГЛАВА 21

ЗНАКОМЬТЕСЬ: ЛИА ХИКМАН ИЗ ADOBE

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; она помогает другим компаниям успешно проходить через серьезную трансформацию и внедрять современные передовые методики работы с продуктами.

ЧАСТЬ III

ПРАВИЛЬНЫЙ ПРОДУКТ

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

ДОРОЖНЫЕ КАРТЫ ПРОДУКТА

ОБЗОР

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

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

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

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

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

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

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

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

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

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

ГЛАВА 22

ПРОБЛЕМЫ ДОРОЖНЫХ КАРТ ПРОДУКТА

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

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

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

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

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

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

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

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

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

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

ГЛАВА 23

АЛЬТЕРНАТИВА ДОРОЖНЫМ КАРТАМ

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

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

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

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

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

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

В технологических компаниях такой бизнес-контекст обеспечивается двумя основными компонентами:

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

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

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

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

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

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

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

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

У такого подхода к работе есть несколько серьезных преимуществ:

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

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

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

При ее использовании во главу угла ставится результат, а не процесс.

В мире, конечно, найдется совсем немного продуктовых команд, которые изменили свои дорожные карты продукта так, чтобы каждый их пункт формулировался как бизнес-проблема, обязательно требующая решения, а не как фича или проект, которые, возможно, решат эту проблему, а может быть, и нет. Такие документы называют дорожными картами, базирующимся на результате. При виде таких карт я обычно бываю безмерно счастлив, потому что, насколько я знаю, в этом случае продуктовые команды нацелены на решение бизнес-проблем, а не на предложение новых фич. Дорожные карты, базирующиеся на результате, можно считать эквивалентом систем, в основе которых лежат бизнес-цели, например системы OKR (Objectives and Key Results — «цели и ключевые результаты»)11. Форма разная, а содержание практически одинаковое.

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

Обязательства с высокими требованиями

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

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

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

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

Так что же делать?

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

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

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

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

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

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

ВИДЕНИЕ ПРОДУКТА

ОБЗОР

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

ГЛАВА 24

ВИДЕНИЕ ПРОДУКТА И СТРАТЕГИЯ ЕГО РАЗВИТИЯ

ВИДЕНИЕ ПРОДУКТА

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

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

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

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

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

СТРАТЕГИЯ ПРОДУКТА

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

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

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

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

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

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

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

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

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

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

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

Определение приоритетов

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

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

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

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

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

ГЛАВА 25

ПРИНЦИПЫ СОЗДАНИЯ ВИДЕНИЯ ПРОДУКТА

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

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

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

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

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

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

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

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

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

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

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

ГЛАВА 26

ПРИНЦИПЫ СТРАТЕГИИ РАЗВИТИЯ ПРОДУКТА

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

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

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

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

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

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

ГЛАВА 27

ПРИНЦИПЫ ПРОДУКТА

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

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

Приведу пример. В 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 проста и основывается на двух принципах:

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

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

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

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

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

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

ГЛАВА 28

МЕТОД OKR

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

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

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

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

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

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

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

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

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

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

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

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

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

ГЛАВА 29

ЦЕЛИ ПРОДУКТОВОЙ КОМАНДЫ

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

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

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

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

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

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

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

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

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

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

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

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

МАСШТАБИРОВАНИЕ: ПРОДУКТ

ОБЗОР

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

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

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

ГЛАВА 30

ЦЕЛИ СОЗДАНИЯ ПРОДУКТА И МАСШТАБИРОВАНИЕ

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

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

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

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

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

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

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

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

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

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

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

ГЛАВА 31

ПРОДВИЖЕНИЕ ПРОДУКТА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГЛАВА 32

ЗНАКОМЬТЕСЬ: АЛЕКС ПРЕССЛАНД ИЗ BBC

Должен признаться вам в своей слабости к британской 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 и сделала потрясающую карьеру в нескольких технологических и медиакомпаниях; сегодня она работает лидером продукта в Нью-Йорке.

ЧАСТЬ IV

ПРАВИЛЬНЫЙ ПРОЦЕСС

В части II мы изучили продуктовые команды, в части III — описали, как решить, на чем они должны сосредоточиться. В части IV я объясню, как эти команды работают. Мы подробно рассмотрим методики, виды деятельности и подходы к работе, которые продуктовые команды используют для того, чтобы раз за разом исследовать новые продукты и поставлять их на рынок.

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

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

ИССЛЕДОВАНИЕ ПРОДУКТА

ОБЗОР

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

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

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

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

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

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

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

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

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

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

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

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

ГЛАВА 33

ПРИНЦИПЫ ИССЛЕДОВАНИЯ ПРОДУКТА

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

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

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

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

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

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

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

Мы не должны рассчитывать на то, что потребители (или руководство, или заинтересованные стороны) подскажут нам, над чем следует работать.

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

Главное — обеспечить реальную ценность продукта.

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

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

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

Функциональность, дизайн и технологии неразрывно связаны.

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

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

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

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

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

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

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

Подтверждать реализуемость идей нужно на этапе исследования, а не позже.

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

Подтверждать бизнес-жизнеспособность идей нужно на этапе исследования, а не позже.

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

Важнейшая грань исследования — совместное обучение.

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

Итак, это были принципы исследования продукта, а все остальное зависит от их соблюдения.

Этика: следует ли нам это создавать?

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

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

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

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

Итерации на этапе исследования продукта

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

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

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

ГЛАВА 34

МЕТОДИКИ ИССЛЕДОВАНИЯ ПРОДУКТА: ОБЗОР

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

МЕТОДИКИ ДЛЯ ФОРМУЛИРОВАНИЯ ЗАДАЧ

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

МЕТОДИКИ ДЛЯ ПЛАНИРОВАНИЯ

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

МЕТОДИКИ ДЛЯ ПОИСКА ИДЕЙ

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

МЕТОДИКИ ПРОТОТИПИРОВАНИЯ

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

МЕТОДИКИ ДЛЯ ТЕСТИРОВАНИЯ

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

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

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

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

ТЕСТИРОВАНИЕ РЕАЛИЗУЕМОСТИ

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

ТЕСТИРОВАНИЕ ЮЗАБИЛИТИ

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

ТЕСТИРОВАНИЕ ЦЕННОСТИ

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

ТЕСТИРОВАНИЕ БИЗНЕС-ЖИЗНЕСПОСОБНОСТИ

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

МЕТОДИКИ ДЛЯ ТРАНСФОРМАЦИИ

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

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

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

МЕТОДИКИ ДЛЯ ФОРМУЛИРОВАНИЯ ЗАДАЧ

ОБЗОР

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее я опишу три мои любимые методики; каждая из них подходит для разных объемов работы.

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

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

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

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

Проблемы против решений

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

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

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

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

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

ГЛАВА 35

МЕТОДИКИ ДЛЯ ОЦЕНКИ ВОЗМОЖНОСТЕЙ

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

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

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

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

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

БИЗНЕС-ЦЕЛЬ

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

КЛЮЧЕВЫЕ РЕЗУЛЬТАТЫ

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

ПРОБЛЕМА КЛИЕНТА

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

ЦЕЛЕВОЙ РЫНОК

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

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

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

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

ГЛАВА 36

МЕТОДИКА «ПИСЬМО КЛИЕНТА»

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

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

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

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

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

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

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

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

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

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

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

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

ГЛАВА 37

МЕТОДИКА «КОНЦЕПЦИЯ СТАРТАПА»

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

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

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

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

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

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

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

Самый большой риск

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

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

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

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

Тут я вынужден сделать две важные оговорки.

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

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

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

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

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

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

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

МЕТОДИКИ ПЛАНИРОВАНИЯ

ОБЗОР

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

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

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

ГЛАВА 38

«КАРТА ИСТОРИИ»

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

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

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

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

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

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

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

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

ГЛАВА 39

ПРОГРАММА ПО ИССЛЕДОВАНИЮ ПОТРЕБИТЕЛЕЙ

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

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

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

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

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

ВЕЛИКАЯ МОЩЬ РЕФЕРЕНСНЫХ КЛИЕНТОВ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ОДИН ЦЕЛЕВОЙ РЫНОК

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

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

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

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

ПОДБОР ПОТЕНЦИАЛЬНЫХ РЕФЕРЕНСНЫХ КЛИЕНТОВ

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

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

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

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

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

ВЗАИМООТНОШЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

А теперь рассмотрим основные варианты реализации программы для разных типов продуктов.

ПЛАТФОРМЕННЫЕ ПРОДУКТЫ/API

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

ИНСТРУМЕНТЫ ДЛЯ ПОДДЕРЖКИ КЛИЕНТОВ

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

ПРОДУКТЫ ДЛЯ ПОТРЕБИТЕЛЕЙ

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

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

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

РЕЗЮМЕ

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

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

Как оценить соответствие «продукт — рынок»

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

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

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

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

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

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

ГЛАВА 40

ЗНАКОМЬТЕСЬ: МАРТИНА ЛАУЧЕНГКО ИЗ MICROSOFT

В 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, а также преподает маркетинг в Калифорнийском университете в Беркли.

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

МЕТОДИКИ ДЛЯ ПОИСКА ИДЕЙ

ОБЗОР

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

Примечательно, что в большинстве компаний — из тех, что не слишком преуспевают в разработке продуктов, — продуктовые команды сами генерируют идеи нечасто. Идеи «спускаются» им в виде расставленных в порядке приоритетности функций и опций — дорожных карт продукта, и большинство пунктов в этих картах взяты либо из запросов крупных (или потенциальных) клиентов, либо поступают от заинтересованных сторон или руководства компании. К сожалению, качество таких идей чаще всего оставляет желать лучшего. Между тем, если продуктовой команде предлагают не решения, над которыми нужно работать, а актуальные бизнес-проблемы, и она выполняет свою работу, напрямую и часто взаимодействуя с реальными пользователями и клиентами, то получить достаточно идей отличного качества не так уж и сложно.

Несколько отличных методик позволяют стабильно снабжать команду весьма перспективными и очень актуальными идеями продукта, над которым стоит работать. Но есть одна важная оговорка: начав использовать их, вы будете удивлены количеством полученных в результате идей. Однако это не значит, что вы должны просто брать быка за рога и реализовывать все. Сначала их необходимо протестировать, чтобы убедиться в их ценности и полезности для потребителей и в том, что они технически выполнимы и выгодны для вашего бизнеса.

ГЛАВА 41

ИНТЕРВЬЮ С ПОЛЬЗОВАТЕЛЕМ

Среди всех методик, о которых рассказывается в книге, интервью с пользователем — основная. Я очень хотел бы, чтобы мне не нужно было включать ее в обсуждение, потому что, на мой взгляд, нам стоило бы исходить из того, что каждый менеджер продукта знает, как проводить ее правильно, и часто использует в своей работе.

К сожалению, это не всегда так. Даже если такие интервью проводятся, менеджер продукта на них часто не присутствует и, как следствие, не принимает полученную из них информацию близко к сердцу, не воспринимает ее так серьезно, как должен (см. принцип исследования продукта № 10, касающийся совместного обучения, в главе 33). А между тем такие интервью, несомненно, один из самых важных навыков для любого продакт-менеджера и очень часто источник вдохновения для многих прорывных идей. При использовании методик для качественного тестирования идей, которые мы будем обсуждать далее, вы увидите, что владение этими навыками — обязательное условие.

Формы интервью с пользователями могут быть разными, так что, строго говоря, это не совсем одна методика. Одни интервью неформальные, другие формальные. В основе одних лежит та или иная методология исследования пользовательского поведения (одна из моих любимых — контекстный запрос); другие нацелены на то, чтобы «вытащить» из человека новые сведения и узнать то, чего мы пока не знаем.

Как бы там ни было, мы можем извлечь те или иные ценные сведения буквально из каждого взаимодействия с пользователем или клиентом. Вот что я всегда пытаюсь узнать в ходе такого общения:

Действительно ли ваши потребители те, кого вы ими считаете?

В самом ли деле они имеют те проблемы, которые вы предполагаете?

Как этот потребитель решает свою проблему сегодня?

Что нужно для того, чтобы он стал использовать ваш продукт?

Способов получить ответы на эти вопросы много, и если у вас есть доступ к хорошему исследователю пользовательского поведения, то обычно вы идете по его «наводкам». Несколько советов позволят вам извлечь максимум пользы из этих возможностей обучения и приобретения нужных знаний.

Частота. Проводите интервью с пользователями с регулярной частотой. Бесполезно делать это лишь время от времени. Минимальная частота — два-три часа каждую неделю.

Главная цель. Во время интервью вы не пытаетесь что-либо доказать потребителю, а лишь хотите лучше понять его запросы и чаяния и быстро узнать что-то новое, что может быть вам полезно. Такой настрой чрезвычайно важен, и он должен быть искренним.

Привлечение пользователей и клиентов. Детальнее мы поговорим об этом, когда будем обсуждать методику тестирования юзабилити, а пока скажу, что нужно всегда стараться общаться в первую очередь с людьми с целевого рынка, на котором вы намерены работать, а для этого вам придется отнять у них около часа.

Место проведения интервью. Всегда полезно и поучительно встречаться с клиентами в их «родной среде обитания». Как много всего можно узнать, просто наблюдая за окружением человека! Но можно встретиться и в другом удобном месте или пригласить пользователя к себе в офис. Делать это по видеосвязи не так хорошо, но все же лучше, чем вообще не общаться с потребителем.

Подготовка. Заранее четко определите, в чем, по-вашему, заключается проблема пользователя. Обдумайте, как вы будете подтверждать или опровергать это предположение.

Кто должен присутствовать. Мой любимый вариант — привлечь к интервью трех человек: продакт-менеджера, дизайнера продукта и одного из инженеров-программистов продуктовой команды (мы обычно по очереди посылаем тех, кто изъявляет желание присутствовать на встрече). Обычно дизайнер ведет беседу (потому что этих специалистов обучают этому), менеджер продукта ведет записи, а разработчик наблюдает.

Собственно интервью. Старайтесь сделать общение естественным и неформальным; задавайте вопросы, требующие развернутого ответа, и пытайтесь как можно детальнее выяснить, как люди борются с интересующей вас проблемой сегодня, а не как им хотелось бы это делать, хотя это тоже интересно.

Последующие действия. После беседы расспросите коллег, чтобы убедиться, что вы все услышали одно и то же и теперь располагаете одинаковыми знаниями. Если во время встречи вы что-нибудь пообещали потребителю, непременно сдержите слово.

Я утверждаю, что час, проведенный в общении с пользователем, всегда отлично окупается. Чрезвычайно важно знать ответы на перечисленные выше ключевые вопросы. А еще я большой поклонник использования больших возможностей интервью с клиентами с целью тестирования некоторых идей относительно продукта. Мы делаем это после того, как узнаем ответы на ключевые вопросы, но это действительно прекрасная возможность, которой мне очень нравится пользоваться.

При обсуждении тестирования юзабилити и ценности продукта мы поговорим и о других методиках. Сейчас же просто запомните, что после интервью с клиентом можно провести пользовательский тест вашей новейшей идеи или замысла продукта.

ГЛАВА 42

КОНСЬЕРЖ-ТЕСТ

Консьерж-тест — одна из моих любимых методик; она позволяет быстро вырабатывать превосходные идеи для продукта и лучше понимать своего потребителя, вызывает эмпатию по отношению к нему, что невероятно важно для мотивации команды и выработки отличных решений.

Консьерж-тест относительно новое название старой, но очень эффективной методики. По его замыслу, мы выполняем работу за потребителя — вручную и лично. Это все равно что попросить портье отеля найти вам, скажем, билеты в театр на популярное шоу. Вы не знаете, как он добудет вам билеты, но знаете, что непременно сделает это каким-то образом.

При использовании этой методики вы становитесь консьержем. Вы делаете за своих пользователей или клиентов то, что в противном случае им пришлось бы делать самим. Возможно, сначала вам придется попросить их провести для вас тренинг, но в итоге вы «влезаете в их шкуру» и делаете то, что делали бы они.

В некотором смысле эта методика похожа (но не то же самое) на рабочий день, проведенный вами в службе поддержки клиентов или с персоналом по управлению успехом клиентов. Такой тест очень полезен еще и тем, что нередко становится источником перспективных идей относительно продукта, но главное — это помощь пользователям, обратившимся к вам со своей проблемой.

Эта методика подразумевает обращение с просьбой к реальному пользователю или клиенту показать вам, как он работает, что позволяет узнать, как он подходит к делу, и благодаря этому выработать более удачное решение его проблемы.

Если вы создаете продукт для обслуживания клиентов, то пользователями будут сотрудники вашей компании, но действовать нужно так же: вы просите коллег научить вас делать их работу. В целях совместного обучения стоит привлекать к участию в консьерж-тесте продакт-менеджера, дизайнера продукта и одного из инженеров-программистов.

ГЛАВА 43

СИЛА «НЕПРАВИЛЬНОГО» ПОВЕДЕНИЯ ПОТРЕБИТЕЛЯ

В прошлом эффективные продуктовые команды использовали два подхода к определению продуктово-рыночных возможностей:

Оценка рыночных возможностей и выбор потенциально прибыльных зон, где существует серьезная проблема.

Оценка и «подгонка» актуальных возможностей технологий или данных, имеющихся в вашем распоряжении, для решения серьезной проблемы.

Вы можете думать о первом подходе как о следовании за рынком, а о втором — за технологией. Каждый из них способен подсказать вам идею отличного нового продукта. Однако сегодня некоторые преуспевающие компании выбирают третий подход, и хотя он годится не для всех, это очень действенный метод, который, к сожалению, недооценен и явно недостаточно часто используется в нашей отрасли. Речь идет о том, чтобы разрешать потребителям и даже поощрять их использовать наши продукты для устранения других проблем, а не только тех, решение которых уже возложено на нас, в отношении которых мы уже обеспечиваем официальную поддержку.

Мой давний друг Майк Фишер написал книгу Power of Customer Misbehavior («Влияние неправильного поведения потребителя»). В ней в основном рассказываются истории лавинообразного роста eBay и Facebook, но есть и несколько других очень интересных примеров.

С первых дней существования eBay на сайте был раздел Everything Else («Все остальное»). Здесь люди могли покупать и продавать вещи, которыми, по нашим ожиданиям, они не должны были бы хотеть торговать. И хотя компания ждала многого (мы предлагали и предлагаем тысячи самых разных категорий), источником некоторых самых смелых инноваций и сюрпризов для нас стал мониторинг того, что хотят делать клиенты. В eBay очень быстро поняли, что именно здесь возникают идеи лучших инноваций, и сделали все возможное, чтобы клиенты развивали торговую площадку компании, поощряя их покупать и продавать что угодно.

Хотя изначально аукцион создавался для облегчения торговли электроникой и предметами коллекционирования, вскоре люди начали торговать билетами на концерты, произведениями искусства и даже автомобилями. И хотите верьте, хотите нет, сегодня eBay считается одной из крупнейших в мире компаний по торговле подержанными авто.

Как вы понимаете, между безопасной покупкой и транспортировкой автомобиля и покупкой билета на концерт мало общего. Поэтому необходимая работа была проделана компанией только после того, как окончательно установился спрос, для чего клиентов обеспечили возможностью заключать сделки на предметы, которых команда и компания не предполагали увидеть, и делать это неожиданными способами.

Те, кто предлагает продукты на рынке, расстраиваются, когда узнают, что потребители используют их детища не так, как подразумевалось. Недовольство обычно связано с обязанностями по поддержке. Но, по-моему, этот особый случай может иметь поистине стратегическое значение и заслуживать любых инвестиций в функцию поддержки клиентов. Так что, если вы обнаружите, что клиенты используют ваш продукт не так, как планировалось, знайте: здесь кроется ценный потенциал. Покопайтесь в этом, чтобы узнать, какую проблему люди пытаются решить таким образом и почему они верят, что ваш продукт способен обеспечить их подходящим фундаментом. Проделайте эту работу, и со временем непременно выявите определенные модели, а вместе с ними, может быть, и некоторые в высшей степени перспективные возможности в плане новых продуктов.

Сила «неправильного» поведения разработчика

В примере eBay речь идет о конечных пользователях (покупателях и продавцах), но то же «неправильное» поведение лежит и в основе тенденции к открытому доступу к некоторым или всем сервисам продукта через интерфейсы прикладного программирования (публичные API). Предлагая публичный API вы, по сути, говорите сообществу разработчиков: «Вот что мы умеем — но, возможно, вы сможете использовать эти сервисы для того, чтобы сделать что-то поистине удивительное, что не пришло нам в голову».

Яркий пример — платформенная стратегия Facebook. Компания открыла доступ к своим профилям в социальной сети, чтобы выявлять, что могли бы сделать разработчики, будь у них возможность использовать этот актив.

Я давний фанат публичных API как неотъемлемого компонента стратегии развития продукта и считаю разработчиков одним из самых стабильных и лучших источников поистине инновационных идей в этом плане. Их положение выгодно с точки зрения понимания того, что возможно на данный момент, и, надо признать, очень многие инновации основаны на их проницательных идеях.

ГЛАВА 44

ХАКАТОН

Хакатоны14 проводятся в самых разных вариациях. В этой главе я опишу одну из своих любимых методик для быстрой выработки множества перспективных идей, решающих насущную проблему потребителя или вашего бизнеса.

Существует две основные разновидности хакатона: целевой и нецелевой. В рамках второго люди исследуют любые приглянувшиеся им идеи относительно продукта, хоть немного связанные с миссией их компании.

В случае целевого хакатона у нас имеется проблема потребителя (скажем, что-то очень трудно освоить или оно занимает слишком много времени) или определенная бизнес-цель (например, «уменьшить показатель оттока клиентов» или «повысить пожизненную ценность клиента»), поэтому мы просим членов продуктовых команд взять инициативу в свои руки и работать с любыми понравившимися им идеями, потенциально способными решить проблему. И главное, эти самоорганизующиеся группы должны изучить и проанализировать выбранные ими идеи, создать прототип в той или иной форме, который можно оценить, и, если дело того стоит, протестировать его на реальных пользователях.

У целевых хакатонов два преимущества: во-первых, практичность, так как методика весьма эффективно способствует включению инженеров-программистов в процесс генерирования идей. Я уже несколько раз упоминал о том, что многие лучшие идеи приходят именно от этих членов продуктовых команд, и нам необходимо воспользоваться такой возможностью. Вообще-то это должно происходить постоянно, и благодаря данной методике мы этого добиваемся. Во-вторых, культурное преимущество. Нужно сказать, это один из моих любимых способов формирования команд «миссионеров». Сегодня — если, конечно, они не сделали этого раньше, — инженеры-программисты все глубже погружаются в бизнес-контекст и играют намного более важную роль в инновациях своих компаний.

МЕТОДИКИ ДЛЯ ПРОТОТИПИРОВАНИЯ

ОБЗОР

Прототипы в различных формах и видах существуют с тех пор, как люди начали использовать технологии для решения проблем. Как говорил известный ученый в области теории вычислительных систем Фредерик Брукс: «Сразу планируйте что-то выбросить — все равно придется».

Эти слова актуальны сегодня не меньше, чем тогда, когда впервые были опубликованы (аж в 1975 году!), но многое с тех пор все же изменилось. Нельзя не отметить значительное повышение эффективности инструментов и методик для создания прототипов и их тестирования, которые имеются в нашем распоряжении.

Тем не менее мне все еще встречаются команды, и даже люди, которых я назвал бы лидерами мнений, на удивление узко интерпретирующие смысл термина прототип. Когда я прошу их пояснить свою позицию, как правило, оказывается, что они ассоциируют этот термин с образцом, который им показали первым. Если первым вы видели образец, использовавшийся для тестирования технических возможностей, вы считаете его прототипом. То же самое с образцом для тестирования юзабилити. На самом деле существует много разных форм прототипов, каждый со своими характеристиками, предназначенных для тестирования разных свойств. И конечно же, пытаясь использовать для решения своих задач неподходящий вид прототипа, люди сталкиваются с серьезными неприятностями.

Далее я кратко расскажу об основных классах прототипов, а в последующих главах мы обсудим каждый из них подробно.

ПРОТОТИПЫ ДЛЯ ТЕСТИРОВАНИЯ РЕАЛИЗУЕМОСТИ ИДЕИ И ПРОДУКТА

Эти прототипы программисты пишут для устранения рисков технической реализации на этапе исследования продукта — еще до того, как решается, осуществима ли идея. Иногда инженеры-программисты тестируют таким образом новую технологию или алгоритм. Часто речь идет об оценке производительности. Суть в том, что разработчик должен написать минимально достаточный код, чтобы устранить или хотя бы снизить этот риск.

ПОЛЬЗОВАТЕЛЬСКИЕ ПРОТОТИПЫ

Пользовательские прототипы — это симуляции. Таких прототипов много — от тех, что намеренно разрабатываются подобно вайрфреймам (в общих чертах набросанные на листе бумаге, или так называемые пользовательские прототипы малой детализации), до тех, которые выглядят и воспринимаются как готовый продукт (их называют пользовательскими прототипами высокой детализации).

ПРОТОТИПЫ НА РЕАЛЬНЫХ ДАННЫХ

Суть прототипов на реальных данных объяснить несколько сложнее, но это чрезвычайно важный инструмент, полезный сразу в нескольких ситуациях. Главная их цель — в сборе фактических данных, чтобы мы могли что-то доказать или хотя бы подтвердить, а чаще всего выяснить, работает ли идея (относительно фичи, дизайнерского решения, рабочего процесса). Как правило, это означает, во-первых, что такой прототип требуется для доступа к своим источникам данных, а во-вторых, что мы должны иметь возможность направлять в него реальный трафик — в достаточном для сбора информативных данных количестве.

И главное, для этого не приходится создавать, тестировать и развертывать жизнеспособный с коммерческой точки зрения продукт. На это ушло бы слишком много времени, стоило бы слишком дорого и, скорее всего, привело бы к огромным напрасным тратам времени и сил. Прототип же обойдется неизмеримо дешевле коммерчески оправданного продукта, что, собственно, и делает методику такой полезной и эффективной.

СМЕШАННЫЕ ПРОТОТИПЫ

Существует также целый ряд прототипов, сочетающих разные аспекты разных образцов. Например, при работе над механизмами поиска и рекомендаций с фокусом на актуальности данных нам может понадобиться прототипный доступ к источникам реальных данных, но настоящий трафик будет не нужен. В этом случае мы ничего не пытаемся доказать или подтвердить, но путем наблюдения и обсуждения полученных результатов с пользователями можем узнать много нового и полезного.

Помните: главная цель исследования продукта — найти максимально быстрый и самый дешевый способ тестирования идей. Так что вы должны выбирать тот вид прототипа, который лучше всего обеспечивает эти потребности применительно к вашей идее и ситуации. У вас могут быть фавориты среди прототипов, но для успешной конкуренции с хорошими продуктовыми командами необходимы навыки и опыт в использовании всех их видов.

ГЛАВА 45

ПРОТОТИПЫ

Как вы убедились, читая предыдущую главу, прототипы бывают разных видов. Выбор зависит от типа риска, который необходимо устранить, и продукта. Но все они имеют ряд общих характеристик и преимуществ. Далее перечислены пять ключевых принципов, из-за которых мы используем этот инструмент.

Общая цель использования любого прототипа — узнать что-то новое и полезное, затратив меньше времени и усилий, чем требуется для создания реального продукта. На разработку любого вида прототипа должно уходить как минимум на порядок меньше времени и сил, чем на конечный продукт.

Одно из преимуществ любого вида прототипа — это то, что его создание заставляет продумать проблему намного глубже, чем в случае, если бы мы просто обсуждали ее или даже формулировали свои мысли письменно. Вот почему этот акт часто выводит на поверхность важные проблемы, которые в противном случае всплывают гораздо позже.

Прототип служит действенным инструментом для совместной работы команды. Члены продуктовой команды и бизнес-партнеры могут вместе испытать его и выработать общий взгляд на проблему.

Прототипы различаются по степени детализации. От этой характеристики зависит, насколько реалистично выглядит прототип. Надо отметить, что такого понятия, как правильная степень детализации, не существует. Иногда нам вовсе не нужно, чтобы прототип выглядел реалистично, в других случаях он должен быть именно таким. Важно обеспечить нужную детализацию применительно к его предназначению, и помнить о том, что малая детализация достигается быстрее и дешевле высокой, поэтому мы нацеливаемся на высокий уровень только тогда, когда это действительно необходимо.

Предназначение любого вида прототипа состоит в устранении одного или нескольких рисков, связанных с продуктом (риск ценности, юзабилити, реализуемости, жизнеспособности), на этапе его исследования. Но во многих случаях этот инструмент дает нам еще одно важное преимущество: помогает максимально четко донести мысль о том, что нужно создать, до инженеров-программистов и других сотрудников компании. Обычно эту задачу называют прототип как технические спецификации. Чаще всего бывает достаточно прототипа, но иногда, особенно тогда, когда программисты работают удаленно или продукт очень сложный, его нужно дополнить информацией — как правило, сценариями использования, правилами делового регламента и критериями приемки.

ГЛАВА 46

ПРОТОТИПЫ ДЛЯ ТЕСТИРОВАНИЯ РЕАЛИЗУЕМОСТИ

В большинстве случаев, проанализировав новые идеи продукта, инженеры-программисты скажут, что у них нет особых причин беспокоиться об имеющихся технических возможностях. Ведь они, скорее всего, уже создавали нечто подобное много раз. Однако в нескольких ситуациях существует значительный риск технической реализуемости. Их разработчики довольно часто выявляют в связи с решением проблемы, над которой работают. Чаще всего причины для беспокойства связаны:

с алгоритмом;

производительностью;

масштабируемостью;

отказоустойчивостью;

проблемами применения технологий, которые команда не использовала ранее;

проблемами при использовании компонентов или сервисов других производителей, которые команда не использовала ранее;

проблемами использования унаследованной системы, которую команда не использовала ранее;

проблемами зависимости от новых или сопутствующих изменений, внесенных другими командами.

Для устранения этих типов рисков используется следующая методика: один или несколько инженеров-программистов создают прототип для тестирования реализуемости. Обычно это делает программист, поскольку, как правило, это код — в отличие от большинства других прототипов, которые создаются с помощью специализированных инструментов, чаще всего предназначенных для использования дизайнерами продукта. До коммерчески поставляемого продукта такому прототипу еще далеко, поэтому необходимо написать такой код, который позволит снизить этот риск. И, как правило, это лишь малая толика работы, которую придется сделать, чтобы получить потенциально выгодный с коммерческой точки зрения продукт. К тому же в большинстве случаев прототип для тестирования реализуемости представляет собой технологическую программу, временно используемую при разработке программного обеспечения, так что результат часто бывает быстрым и довольно «грязным», но это нормально. Предположительно его будет достаточно для сбора данных, чтобы, например, продемонстрировать, что производительность, скорее всего, будет приемлемой — либо неприемлемой. Пользовательский интерфейс, механизмы обработки ошибок и любая типичная работа по коммерческому внедрению продукта тут обычно не нужны.

По моему опыту, на создание прототипа для тестирования реализуемости уходит не более двух дней. Но если вы работаете над сложными новыми технологиями, скажем над новым подходом с использованием технологии машинного обучения, то для создания такого прототипа понадобится больше времени. Сколько, оценивают инженеры-программисты. А вот будет ли команда этим заниматься, зависит от менеджера продукта: он решает, стоит ли продолжать работу над идеей. Он может сказать, что другие подходы к решению проблемы не чреваты риском реализуемости, и предпочтет отказаться от этой идеи.

Хотя созданием прототипа для тестирования этого вида риска обычно занимаются инженеры-программисты, эту работу относят к этапу исследования продукта, а не его поставки на рынок. Она выполняется в рамках принятия решения, следует ли вообще развивать этот подход или идею.

Скажу несколько слов о том, какие уроки я извлек из этого. Мне не раз приходилось видеть, как команды переходят к этапу поставки, не оценив в должной мере риска реализуемости. Каждый раз, когда вы слышите истории о продуктовых командах, недооценивших объем работ по созданию и поставке чего-либо стоящего, знайте: главная проблема данного просчета кроется именно в этом. Может быть, у разработчиков не было опыта в правильной оценке перспектив, или инженеры и менеджер продукта не в полной мере понимали, что для этого нужно, или последний не дал инженерам-программистам достаточно времени на изучение и анализ ситуации.

ГЛАВА 47

ПОЛЬЗОВАТЕЛЬСКИЕ ПРОТОТИПЫ

Пользовательский прототип, или симуляция — один из самых эффективных инструментов на этапе исследования продукта. Это дым и зеркала. Фасад, за которым ничего нет. Занавес, за которым пустота. Простыми словами, если речь идет о пользовательском прототипе интернет-магазина, то человек может вводить данные своей кредитной карты хоть сто раз, ничего не покупая.

Спектр пользовательских прототипов весьма широк. На одном его конце находятся опытные образцы малой детализации. Они не похожи на реальный продукт; по сути, это просто интерактивный вайрфрейм. Многие команды используют их для всестороннего обдумывания продукта в тесном кругу коллег, но есть и другие способы применения этого метода.

Следует помнить, что пользовательские прототипы малой детализации представляют только один аспект продукта — информацию и рабочий процесс, но ничего не говорят о влиянии графического дизайна или различиях, возникающих при поступлении реальных данных. Это лишь два примера, которых на самом деле множество.

На другом конце спектра находятся пользовательские прототипы высокой детализации. Несмотря на то что это тоже симуляция, она выглядит и воспринимается как нечто весьма реалистичное. Часто их даже не отличишь от настоящего продукта. Тем не менее это не так; данные, которые вы видите, не реальные, хоть и очень похожие.

В примере с пользовательским прототипом для сайта электронной коммерции вы вводите запрос об определенном горном велосипеде, и на экране возникает один и тот же список таких транспортных средств. Но если присмотреться, это не те велосипеды, которые вы запрашивали. И еще, каждый раз вы получите выборку одних и тех же велосипедов, какую бы цену или модификацию ни указали. Иными словами, если нужно проверить релевантность результатов поиска, этот инструмент вам не подходит. Но если вы собираетесь придумать хороший общий опыт совершения покупок или выяснить предпочтения пользователей в плане поиска, такого прототипа будет более чем достаточно, а создается он очень быстро и легко.

Существует множество инструментов для создания пользовательских прототипов — для разных устройств, с разной степенью детализации. В основном их разрабатывают для дизайнеров продуктов. У вашего дизайнера несомненно есть как минимум один, а то и несколько любимых инструментов пользовательского прототипирования. Некоторые дизайнеры предпочитают писать код для своих опытных образцов высокой детализации вручную, что в принципе нормально, если, конечно, они работают быстро и готовы относиться к прототипу как к одноразовому инструменту.

Существенное ограничение пользовательского прототипа состоит в том, что он ничего не доказывает. Скажем, не дает гарантии, что ваш продукт будет продаваться.

Многие начинающие разработчики новых продуктов попадают в ловушку, создавая пользовательский прототип высокой детализации и предлагая его 10–15 человекам, которые в один голос подтверждают его великолепие. Создатель думает, что проверил свой продукт и подтвердил его соответствие предъявляемым требованиям, но, увы, ошибается. Люди часто говорят одно, а поступают совершенно иначе.

Есть более надежные методы для подтверждения ценности продукта, и вы обязаны знать, что пользовательский прототип в их число не входит. И все же в арсенале продуктовых команд это очень серьезное оружие, и вам следует развивать навыки и опыт своей команды в создании пользовательских прототипов любой степени детализации. Как вы убедитесь в следующих главах, для некоторых типов подтверждения правильности идеи пользовательский прототип очень нужен. К тому же это один из важнейших инструментов коммуникации.

ГЛАВА 48

ПРОТОТИПЫ НА РЕАЛЬНЫХ ДАННЫХ

Иногда для снижения серьезного риска, выявленного на этапе исследования продукта, нам нужна возможность собирать фактические данные о его использовании. Но делать это необходимо именно на этапе исследования, то есть задолго до того, как вы потратите время и силы на создание реального и масштабируемого готового продукта.

Мои любимые примеры использования этого вида прототипа связаны с применением динамики игры, релевантности результатов поиска, социальных фич и «воронки» работы над продуктом. Для этого, собственно, и предназначены прототипы на реальных данных.

Имплементация прототипа на реальных данных очень ограниченна. Обычно она не включает в себя ничего, что требуется для коммерческого внедрения продукта: ни полного набора сценариев использования, ни автоматизированных тестов, ни аналитического инструментария, ни возможностей интернационализации и локализации продукта, ни его производительности и масштабируемости. Ничего этого не требуется.

Прототип данного вида существенно меньше того, что будет создан со временем на его основе, поэтому планка качества, производительности и функциональности устанавливается значительно ниже. Он должен в достаточной мере эффективно собирать данные для некоторых очень специфических сценариев использования — вот и все его предназначение.

При создании прототипа на реальных данных инженеры не нацеливаются на все возможные сценарии использования. Они не решают вопросы поддержки интернационализации и локализации продукта, не занимаются вопросами производительности или масштабируемости, не разрабатывают автоматизированные тесты и включают в прототип только инструментарий для специфических вариантов использования, которые мы тестируем.

Прототип на реальных данных — это лишь малая толика работы, которая проделывается для полноценного вывода продукта на рынок (по моему опыту, на него уходит 5–10 процентов всей работы над готовым продуктом), но получаемую от него пользу переоценить невозможно. Однако следует помнить о двух существенных ограничениях:

Поскольку речь идет о коде, создавать такие прототипы должны инженеры-программисты, а не дизайнеры.

Поскольку это не окончательный продукт, готовый к выведению на рынок, бизнес на нем не сделаешь. Так что, если тесты на реальных данных проходят успешно и вы решаете выходить с продуктом на рынок, придется предоставить программистам достаточно времени для выполнения всей дальнейшей необходимой работы. Менеджер продукта не должен говорить инженерам, что все «уже и так, как надо»; это неправильно. Решение принимает не он. Однако он обязан гарантировать, что руководство компании и ключевые заинтересованные стороны в полной мере понимают ограничения прототипа данного вида.

Сегодня технология создания прототипов на реальных данных настолько эффективна, что мы часто можем получить нужное за два дня, максимум за неделю, после чего придется очень быстро выполнить требуемое количество итераций.

Позже мы обсудим количественные методики для подтверждения надежности идей и продуктов, и вы увидите разные способы применения прототипа на реальных данных. А пока запомните: главное — иметь возможность направить на такой прототип некоторый ограниченный объем трафика и собирать аналитику о его использовании.

Реальные пользователи будут применять ваш прототип в настоящей работе и генерировать подлинные данные (пригодные для аналитики), которые мы можем сравнить с данными о текущем продукте или со своими ожиданиями и увидеть, дает ли новый подход лучшие результаты. Вот что важно!

ГЛАВА 49

СМЕШАННЫЕ ПРОТОТИПЫ

Итак, мы поговорили о пользовательских прототипах, или симуляциях, прототипах для проверки и устранения рисков, связанных с технической выполнимостью, и прототипах на реальных данных, предназначенных для подтверждения или даже получения статистически значимых доказательств эффективности нового продукта или идеи. Эти три вида прототипов отлично справляются с большинством ситуаций, однако существует огромное разнообразие смешанных прототипов, в которых по-разному сочетаются различные аспекты названной троицы.

Один из моих любимых смешанных прототипов и исключительно эффективный инструмент для быстрого обучения людей на этапе исследования продукта часто называют «волшебником страны Оз». Он состоит из проработанного интерфейса пользовательского прототипа с высокой степенью детализации и реального человека, который, стоя «за ширмой», как великий и ужасный Гудвин, вручную выполняет то, что в итоге будет делаться автоматически.

Прототип этого вида не подлежит масштабированию, и никто не стал бы направлять на него сколько-нибудь значительный объем трафика. Его главное преимущество, с нашей точки зрения, заключается в том, что он создается быстро и легко, а в глазах пользователя выглядит и ведет себя как реальный продукт.

Представьте, что вы предлагаете потребителям некий вид онлайн-консультаций (живой чат), но они доступны только в часы, когда ваш персонал по обслуживанию клиентов находится в офисе. Но вы знаете, что клиенты используют этот продукт во всех уголках мира, в любое время суток, поэтому хотели бы разработать автоматизированную систему на основе чата, которая давала бы полезные консультации круглосуточно.

Конечно, вы можете (и должны) расспрашивать сотрудников службы поддержки клиентов о типичных запросах и о том, как они на них обычно отвечают (для чего, кстати, отлично подходит консьерж-тест, позволяющий быстро собрать нужные сведения). Однако довольно скоро вам придется решить непростую задачу автоматизации этого процесса. Чтобы очень быстро протестировать несколько возможных подходов к ее решению, нужно создать прототип «волшебник из страны Оз», который обеспечит вас простым интерфейсом на основе чата. За «ширмой» будете сидеть вы, продакт-менеджер, или другой член команды, который будет получать запросы и составлять на них ответы. Скоро вы начнете экспериментировать с ответами системы и, возможно, даже используете прототип на реальных данных для своего алгоритма.

Смешанные прототипы — наглядный пример главной философской идеи в исследовании продукта: создавай то, что не поддается масштабированию. Подойдя к делу разумнее, мы научимся быстро и легко создавать инструменты, которые позволяют нам очень быстро учиться и приобретать новые ценные сведения. Конечно, это преимущественно качественное обучение, но именно оттуда мы нередко черпаем самые важные познания и проницательные идеи.

МЕТОДИКИ ДЛЯ ТЕСТИРОВАНИЯ НА ЭТАПЕ ИССЛЕДОВАНИЯ ПРОДУКТА

ОБЗОР

При исследовании продукта мы пытаемся рассортировать хорошие и плохие идеи и одновременно решить поставленные перед нами бизнес-проблемы. Что в действительности это означает?

На этом этапе мы обдумываем четыре вопроса:

Будет ли пользователь или клиент использовать продукт, захочет ли он его купить? (Ценность.)

Сможет ли пользователь понять, как он работает? (Юзабилити.)

Сможем ли мы создать продукт с технической точки зрения? (Выполнимость.)

Способствует ли это решение жизнеспособности нашего бизнеса? (Бизнес-жизнеспособность.)

Во многих случаях на большинство или даже на все эти вопросы ответить очень просто, и они не сопряжены со сколь-нибудь значимым риском. Ваша команда уверена в своих силах; она много раз делала это раньше, и мы смело переходим на этап поставки продукта на рынок. Большая работа на этапе исследования нужна в случае, когда ответы на эти вопросы неоднозначны.

Должен заметить, что порядок, в котором нужно отвечать на эти вопросы, не предписан, но многие команды следуют определенной логике. Первым делом мы обычно изучаем ценность идеи. Часто это самый сложный и главный вопрос, так как при отсутствии ценности все остальное не имеет значения. Нередко нам приходится решать проблему риска юзабилити до того, как потребитель сумеет распознать ценность нашего предложения. В любом случае мы анализируем юзабилити и ценность одновременно, с привлечением одних и тех же пользователей и клиентов.

Как только становится ясно, что у нас есть разработка, которую потребители считают ценной, и она спроектирована так, что, по нашему мнению, пользователи смогут разобраться в принципах ее работы, приходит время проанализировать этот подход с инженерами, чтобы убедиться в осуществимости замысла с технической точки зрения. Если и тут результаты обнадеживают, мы показываем свою идею в компании всем, у кого могут возникнуть в связи с новым продуктом вопросы или сомнения: юристам, маркетологам, продавцам, СЕО и прочим специалистам. Обычно эти бизнес-риски оцениваются в последнюю очередь, ведь никому не хочется «расшевелить улей», пока он не уверен в том, что дело того стоит. Случается, идеи, дожившие до этого момента, совсем не похожи на те, с которых вы начинали, а нередко были предложены одной из упомянутых выше заинтересованных сторон. Так что гораздо лучше представить им какие-либо подтверждения того, что в их идее потребителям не все понравилось, и объяснить все внесенные изменения.

ГЛАВА 50

ТЕСТИРОВАНИЕ ЮЗАБИЛИТИ

Тестирование юзабилити, как правило, наиболее продуманная и понятная форма тестирования на этапе исследования продукта, используемая уже много лет. Конечно, сегодня инструменты стали намного эффективнее, и команды проводят такие тесты гораздо чаще, чем раньше, но и в целом это не самый сложный вид деятельности. Главное отличие от тестирования юзабилити в прошлом — его проведение на этапе исследования — с использованием прототипов, а не готовых продуктов — а не в конце процесса, когда исправления и коррекции сопряжены со значительными непродуктивными тратами, а то и с чем-то похуже.

Если ваша компания достаточно велика и в ней есть собственная группа исследователей пользователей, во что бы то ни стало добейтесь, чтобы эти люди как можно больше времени работали на вашу команду. Даже если этого времени будет не очень много, такие специалисты обычно представляют собой потрясающий ресурс для менеджера продукта; и если вы сможете подружиться с кем-то из них, то получите отличное подспорье.

Если компания располагает средствами для привлечения сторонних сервисов, можно воспользоваться для тестирования своих идей и продуктов услугами одной из множества фирм, специализирующихся на исследовании пользователей. Однако из-за цены, взимаемой большинством из них, скорее всего, вы не сможете себе позволить такой подход к тестированию юзабилити в нужном объеме. Дело в том, что если вы похожи на большинство компаний, то у вас не слишком много ресурсов и еще меньше денег. Но это ни в коем случае не должно помешать вам работать в этом важнейшем направлении.

А теперь я расскажу, как проводить тестирование юзабилити идеи или нового продукта самостоятельно. Нет, это не позволит вам достичь эффективности специально обученного и подготовленного исследователя, по крайней мере поначалу, и, скорее всего, понадобится провести не одну серию тестов, чтобы в нем поднатореть, но в большинстве случаев вы сможете практически с самого начала самостоятельно выявлять самые серьезные проблемные области продукта, а это, безусловно, очень и очень важно.

В отличных книгах подробно описывается, как проводить неофициальное тестирование юзабилити, но я не стану пересказывать их содержание, а обращу ваше внимание на ряд наиболее существенных моментов.

КАК ПОДОБРАТЬ ПОЛЬЗОВАТЕЛЕЙ ДЛЯ УЧАСТИЯ В ТЕСТИРОВАНИИ

Прежде всего нужно собрать группу объектов исследования. Если у вас есть особая команда исследователей пользователей, то подбирать людей и планировать тесты будут они; и это огромное подспорье. Но если вам приходится делать все самим, в вашем распоряжении есть несколько вариантов:

Если в компании реализуется программа определения потребителей, которую я подробно описывал ранее, вы всегда готовы к этой задаче — по крайней мере когда работаете над продуктом для корпоративных клиентов. Если же вы создаете потребительский продукт, придется дополнить имеющуюся группу.

Для привлечения участников к тестированию можно разместить приглашение на сайте электронных объявлений или осуществить поиск в сети с использованием сервиса Google Ads — что особенно правильно в случае, если вы ищете пользователей, которые в настоящий момент пробуют продукт, похожий на ваш.

Если у вас есть список адресов электронной почты ваших пользователей, можете отобрать участников из него. А продуктовый маркетолог поможет вам сократить выборку.

Можно привлекать волонтеров на сайте своей компании — сегодня многие крупные организации с удовольствием участвуют в тестированиях. Однако волонтеров всегда нужно проверять, чтобы все отобранные люди относились к вашему целевому рынку.

Вы всегда можете пойти в места, где собираются ваши пользователи: торговые выставки софта для бизнес-клиентов, маркетплейсы, спорт-бары для любителей фэнтези-спорта и другие. Если продукт предназначен для удовлетворения какой-нибудь реальной потребности, у вас не будет недостатка в тех, кто согласится потратить на вас час или два. И кстати, захватите с собой символические подарки, чтобы раздать их в знак благодарности за внимание.

Если вы просите пользователей прийти для участия в тестировании к вам, скорее всего, нужно будет им чем-то компенсировать это одолжение. Мы обыкновенно организуем встречи с участниками тестов там, где удобно всем, например в кафе Starbucks. Такая практика стала настолько широко распространенной, что у нее даже появилось название — starbucks-тестирование.

ПОДГОТОВКА ТЕСТА

Юзабилити-тестирование обычно проводится с применением пользовательского прототипа высокой детализации. Собрать полезные сведения о юзабилити можно и с помощью пользовательского прототипа средней детализации, но для изучения ценности, которое обычно проводится сразу после этого теста, все равно понадобится более реалистичный продукт (о причинах этого я расскажу чуть позже).

В большинстве случаев в тестировании юзабилити и (или) ценности участвуют продакт, дизайнер продукта и один из инженеров-программистов команды (из тех, кому нравится посещать такие мероприятия). Я стараюсь привлекать наших разработчиков по очереди. Как я уже упоминал, в присутствии инженера-программиста нередко возникает некое волшебство, поэтому я стараюсь по возможности всегда привлекать таких специалистов. Если в тестировании вам помогает сторонняя компания по исследованию пользователей, управляет тестом обычно она, но ваши продакт-менеджер и дизайнер обязательно должны присутствовать на каждом тесте.

Следует заранее определить набор задач для тестирования. Обычно тут все просто. Если вы разрабатываете, скажем, приложение для будильника на мобильном устройстве, то пользователям придется устанавливать будильник, находить и нажимать кнопку повтора и так далее. Встречаются и менее очевидные задачи, но при тестировании юзабилити нужно сосредоточиться на основных, то есть на тех, которые будут выполняться чаще всего.

Некоторые до сих пор считают, что продакт-менеджер и дизайнер продукта слишком к нему привязаны, поэтому не способны объективно провести тестирование юзабилити; что полученный результат может глубоко ранить их чувства; что они будут слышать только то, что хотят услышать. Такое препятствие устраняется двумя способами: во-первых, путем обучения продакт-менеджеров и дизайнеров поведению в ходе тестирования; во-вторых, как можно более ранним и быстрым проведением тестов, прежде чем создатели продукта влюбятся в свои детища. Хороший продакт знает, что поначалу любой продукт «неправильный», ведь никто не способен сделать все правильно с первого раза. И ему известно, что знания, полученные благодаря этим тестам, — самый скорый и верный путь к успеху в разработке.

Следите за тем, чтобы юзабилити-тест проводил один человек, а записи вел другой. Очень полезно потом все обсудить и убедиться, что оба видели одно и то же и пришли к одинаковым выводам, для этого и нужен второй участник с вашей стороны.

В формальных средах для проведения тестирования обычно организуются помещения с двусторонними зеркалами или специальные видеомониторы с камерами, которые показывают и экран, и лицо пользователя. Прекрасно — иметь такое оборудование, но я даже не могу сосчитать, сколько прототипов мы протестировали за крошечным столиком в Starbucks — таким крошечным, что больше трех-четырех стульев за ним не помещалось. Во многих отношениях кафе даже предпочтительнее отлично оборудованной лаборатории: в неформальной обстановке пользователь не чувствует себя подопытным кроликом.

Еще одна превосходная среда для тестирования — офис потребителя. На реализацию такого подхода может уйти много времени, но даже полчаса, проведенные «в среде обитания» пользователя, расскажут вам о нем очень много полезного. Здесь ваши потребители хозяева, поэтому они намного разговорчивее. В офисе всегда найдется множество подсказок, как еще можно использовать тестируемый продукт. Многое можно узнать при виде офисной обстановки. Насколько большие мониторы? Как быстро работает компьютер и подключение к сети? Как люди общаются с коллегами при решении рабочих задач?

Сегодня в нашем распоряжении имеются инструменты для проведения данного типа тестирования удаленно, и я приветствую это двумя руками. Однако не забывайте, что они предназначены для тестирования юзабилити, а не ценности; вторые тесты обычно проводятся сразу после первых. Иными словами, я рассматриваю удаленное тестирование юзабилити как дополнение, а не замену обычному.

ТЕСТИРОВАНИЕ ПРОТОТИПА

Итак, прототип готов, участники тестирования отобраны, задачи и вопросы сформулированы, теперь воспользуйтесь приведенными ниже советами и методиками для проведения теста.

Первым делом узнайте, что потребители думают о проблеме в настоящий момент. Вы же, конечно, помните, какие ключевые вопросы задаются в рамках методики «Интервью с клиентом»; нам нужно узнать, действительно ли пользователь или клиент столкнулся с той проблемой, которую мы выделили, как он решает ее сегодня и что нужно для того, чтобы убедить его использовать наш продукт.

В начале теста юзабилити обязательно сообщите участникам, что это всего лишь прототип, сырая идея, а не настоящий продукт, и объясните, что они не обидят вас откровенным как позитивным, так и негативным отзывом. Вы тестируете на прототипе идеи, а не пользователей, и они не могут пройти или провалить тест — это грозит только вашему прототипу.

Прежде чем приступить к выполнению своих задач, посмотрите, могут ли пользователи по начальной (посадочной) странице прототипа определить, что вы, собственно, пытаетесь сделать, и особенно то, что, с их точки зрения, может быть ценным или привлекательным. Как только люди приступят к выполнению задания, контекст посетителя-новичка исчезнет, так что не упускайте такую отличную возможность. Увидите: для преодоления разрыва между ожиданиями пользователя и тем, что продукт предлагает ему на самом деле, невероятно важны начальные (посадочные) страницы.

В ходе тестирования нужно делать все от вас зависящее, чтобы удерживать участников в режиме использования и не давать им перейти к критике. Важно определить, могут ли пользователи, применяя ваш прототип, легко выполнять необходимые им задачи, а не то, считают ли они тот или иной элемент страницы недостаточно привлекательным или что, по их мнению, на ней нужно что-то переместить или изменить. Иногда люди, не слишком поднаторевшие в тестировании, задают пользователям неправильные вопросы: «Какие три элемента на странице вы изменили бы?» Меня подобные вещи не очень интересуют — разве что если этот человек по стечению обстоятельств еще и дизайнер продукта. Если бы пользователи знали, чего они на самом деле хотят, создавать программное обеспечение было бы намного проще. Так что обращайте внимание на то, что они делают, а не на то, что говорят.

Для успешного тестирования очень важно сохранять олимпийское спокойствие. Видя, что у человека что-то не получается, у большинства из нас возникает естественное желание прийти на помощь. Вы должны всеми силами подавлять его в себе. Ваша задача — превратиться в нелюдима, не готового поддерживать приятную беседу. Станьте максимально молчаливым; тишина — лучший помощник тестировщика.

В ходе тестирования стоит ожидать развития событий по трем основным сценариям: 1) пользователь справился с задачей без малейших проблем и посторонней помощи; 2) пользователь немного помучился и поворчал, но выполнил нужную задачу; 3) он так измучился и расстроился, что в конце концов сдался, но так и не сделал того, что хотел. Конечно, иногда люди сдаются очень быстро, и вам, возможно, придется уговаривать их продолжить попытки. Но если дело доходит до момента, когда, судя по поведению пользователя, он точно откажется от вашего продукта и перейдет к конкуренту, можно сделать пометку, что пользователь сдался.

Тестировщику нужно стараться не помогать и не задавать участнику тестирования наводящие вопросы. Но если вы видите, что пользователь в сотый раз прокручивает страницу вверх-вниз, явно что-то разыскивая, спросите его, что он ищет, так как эта информация может оказаться очень полезной. Некоторые тестировщики даже просят пользователей в ходе теста постоянно рассказывать, о чем они думают, но, по-моему, это настраивает людей на критику, а такое поведение для нас нежелательно.

Повторяйте за собеседником как попугай, так как это полезно во многих ситуациях и помогает не давать пользователю наводок. Если участник тестирования ничего не говорит, а у вас уже нет сил молчать, опишите ему, что он делает: «Я вижу, вы ищете этот список справа». Человек обязательно расскажет вам, что он пытается сделать, что хочет найти и все остальное. Если же он задаст прямой вопрос, вместо ответа-подсказки можно просто повторить его слова. Например, пользователь спрашивает: «А если кликнуть тут, будет новая запись?» — а вы отвечаете: «Вам интересно, нужно ли кликнуть здесь, чтобы получить новую запись?» Как правило, пользователи «покупаются» на такой прием, потому что люди обычно хотят ответить на заданный им вопрос: «Ну да, думаю, так и будет». А еще попугайничанье помогает избегать наводящих оценочных суждений. Если у вас возникло непреодолимое желание похвалить участника тестирования, лучше скажите: «Ну вот, вы создали новую запись». И наконец, по-попугайски повторяя ключевые моменты, вы помогаете коллеге, который ведет записи, оставляя ему на это больше времени.

Вы пытаетесь разобраться, как целевые пользователи подходят к осмыслению тестируемой проблемы, и выявить в своем прототипе слабые места, в которых модель, представленная данным софтом, не согласуется с ходом рассуждений и действий пользователя. В этом случае она нелогична. К счастью, заметив это на этапе тестирования, мы можем без особого труда все исправить, что нередко становится решающим фактором в успехе будущего продукта.

Вы также скоро обнаружите, что очень многое можно узнать по жестам и тону участников тестирования. Обычно бывает очевидно, нравятся или не нравятся людям ваши идеи. Если пользователям по душе то, с чем они столкнулись, они почти всегда просят вас им сообщить, как только продукт выйдет на рынок. А если ваше детище им очень понравилось, то постараются заполучить его и раньше.

ВЫВОДЫ ИЗ РЕЗУЛЬТАТОВ ТЕСТИРОВАНИЯ

Цель тестирования прототипа — как можно лучше понять своих пользователей и клиентов и, конечно же, выявить в прототипе слабые места, чтобы как можно раньше их устранить. Например, это могут быть проблемы со спецификациями, потоком, графическим дизайном или ментальной моделью работы продукта. Выявив их, сразу же исправьте.

Тест не должен быть одинаковым для всех участников тестирования прототипа. Такая установка базировалась бы на непонимании роли этого вида качественного тестирования. Проводя тест, мы не пытаемся что-либо доказать, а хотим быстро получить ценную информацию.

После каждого тестирования или каждой серии тестов кто-нибудь, обычно продакт-менеджер или дизайнер, составляет резюме полученных результатов и рассылает их по электронной почте членам продуктовой команды. Не нужно составлять эти отчеты долго, они не должны быть длинными. Их редко дочитывают до конца, и они устаревают раньше, чем люди их получат. Ведь к этому моменту прототип, как правило, уже ушел далеко вперед по сравнению с тем, каким был на момент проведения теста. Такие отчеты не стоят потраченных сил и времени.

ГЛАВА 51

ТЕСТИРОВАНИЕ ЦЕННОСТИ

Потребители не обязаны покупать наши продукты, а пользователи — выбирать новую фичу, предложенную вами. Люди будут делать это лишь в случае, если увидят в них ценность. То же самое можно сказать и по-другому: то, что кто-то может использовать наш продукт, еще не означает, что он решит это сделать. Повторяйте себе этот тезис, когда пытаетесь убедить клиентов или пользователей переключиться на ваш новый продукт с того, которым они пользуются.

Очень многие компании и продуктовые команды думают, что им достаточно всего лишь предложить потребителю приблизительно тот же набор функций (обеспечить паритет функциональных возможностей), а потом недоумевают, почему их продукт не продается даже по цене ниже той, что люди платили до появления их детища на рынке.

Чтобы мотивировать потребителя раскошелиться на ваш продукт и пережить все сложности перехода со старого, привычного решения, он должен воспринимать ваше предложение как нечто значительно лучшее. Иными словами, я хотел донести до вас мысль, что хорошие продуктовые команды огромную часть времени уделяют созданию ценности. При наличии ценности можно улучшить и все остальное. В противном случае не имеет значения, насколько удобен, надежен и производителен наш продукт.

Ценность программного продукта состоит из нескольких составляющих, для каждой из которых применяются особые методики тестирования.

ТЕСТИРОВАНИЕ СПРОСА

Иногда довольно трудно определить, есть ли спрос на то, что мы хотим создать. Возможно, нам под силу найти потрясающее решение проблемы, но волнует ли она потребителей? И если да, то в достаточной ли степени, чтобы они купили новый продукт и стали им пользоваться? Стоит отметить, что такой подход к тестированию спроса относится к продукту в целом, в том числе к отдельным функциям уже существующего продукта.

Нельзя просто предположить, что спрос на наше предложение есть, хотя нередко это действительно так. Ведь наши продукты выходят на уже существующий рынок, где спрос уже продемонстрирован, а часто даже и оценен. Настоящая трудность — это предложить решение, ценность которого будет очевидно выше всех его альтернатив.

КАЧЕСТВЕННОЕ ТЕСТИРОВАНИЕ ЦЕННОСТИ

Самый распространенный тип качественного тестирования ценности сосредоточен на отзывах. Нравится ли идея клиентам? Готовы ли они за нее платить? Решат ли ее использовать? И главное, почему нет?

КОЛИЧЕСТВЕННОЕ ТЕСТИРОВАНИЕ ЦЕННОСТИ

Нам нужно протестировать эффективность многих продуктов. Насколько успешно они решают проблему, ради избавления от которой создавались? Для одних типов продуктов такая оценка в высшей мере объективная, количественная. Например, мы можем измерить полученный благодаря рекламным технологиям доход и без особого труда сравнить его с тем же показателем других рекламных технологий. Но для других типов продуктов, например игр, такая оценка будет намного менее объективной.

ГЛАВА 52

МЕТОДИКИ ТЕСТИРОВАНИЯ СПРОСА

К непродуктивным тратам сил и времени относятся случаи, когда команда разрабатывает и создает продукт (тестирует юзабилити, надежность, производительность; делает все, что, по ее мнению, нужно сделать), а после его выхода на рынок обнаруживает, что люди его не покупают. По этой причине стартапы часто терпят крах. Хуже всего не те случаи, когда пользователи, массово подписавшись на пробную версию, потом вдруг решают не покупать продукт. Тут-то еще все можно исправить. Но ведь иногда они не хотят даже подписываться на пробную версию. И вот это действительно огромная, часто роковая проблема.

Вы можете сколько угодно экспериментировать с ценообразованием, позиционированием и маркетингом, но в финале придете к выводу, что предложили решение такой проблемы, которая не так уж и беспокоит людей. Наихудшее в подобном развитии событий то, что, судя по моему опыту, его легко избежать.

Описанная проблема может возникнуть и на уровне продукта, скажем совершенно нового продукта стартапа, и на уровне отдельных опций. Удручающе часто встречается второй вариант. Каждый день пользователям предлагают новые функциональные возможности, которыми они не хотят пользоваться. А между тем предотвратить такую ситуацию просто.

Предположим, вы обдумываете новую функцию, например, потому, что один из крупных клиентов пожелал ее иметь, или вы видели такую у конкурента, или, скажем, она очень нравится вашему СЕО. Вы рассказываете о ней команде, и инженеры-программисты сразу же заявляют, что реализация этой идеи влетит вам в копеечку. Не так уж невозможно осуществить ваш замысел, но и не слишком легко. Достаточно трудно, чтобы вы не пожелали, потратив на это время, в итоге обнаружить, что ее никто не использует. И вы тестируете новую опцию.

Такой метод тестирования спроса называют тестом с поддельными дверями (Fake-door demand test). Мы помещаем кнопку или пункт меню в том месте пользовательского интерфейса, где, по нашему мнению, они должны быть. Но когда пользователь на нем кликает, то он, вместо того чтобы привести к новой опции, переводит его на специальную страницу, где человеку объясняют, что вы исследуете возможность добавления новой опции и очень хотели бы с ним это обсудить. На этой странице пользователю также предлагают стать волонтером в тестировании спроса — например, указав свой адрес электронной почты или номер телефона.

Нужно отметить, что этот подход будет эффективным только в том случае, если пользователь не увидит ни одного признака, который подскажет ему, что это тест, до тех пор пока не кликнет на кнопке или пункте меню. Преимущество этой методики состоит в том, что с ее помощью можно быстро собрать очень полезные данные, которые позволят сравнить рейтинг кликов по кнопке с нашими ожиданиями или другими функциями. И тогда мы можем еще раз связаться с потребителями и глубже разобраться в их запросах и ожиданиях.

То же самое применимо и ко всему продукту. Но в этом случае речь идет не о кнопке на странице — мы настраиваем посадочную страницу на «воронку» нового предложения. Этот метод называют тестом на спрос с использованием посадочной страницы. Новое предложение описывается точно так же, как если бы мы действительно запускали сервис. Однако когда пользователь кликает на кнопке призыва к действию, вместо того чтобы подписаться на пробную версию (или другое действие), он видит страницу, где ему объясняют, что вы изучаете возможность добавления нового предложения и в случае его согласия хотели бы поговорить с ним об этом.

При использовании обоих описанных методов тестирования спроса мы можем показать свой тест либо каждому пользователю (если мы стартап), либо очень маленькому их проценту, либо только тем, кто относится к определенному географическому сегменту (если речь идет о крупной компании).

Надеюсь, вы очень скоро сами убедитесь в несложности этого метода. Благодаря ему можно быстро приобрести сразу два серьезных преимущества: заполучить надежное подтверждение спроса на ваше предложение и составить список пользователей, которые готовы и желают говорить с вами о новой функциональной возможности.

На практике получить спрос обычно несложно. Люди охотно подписываются на пробные версии продуктов. Трудности начинаются тогда, когда они пробуют продукт и он не производит на них впечатления — достаточно сильного, чтобы отказаться от продукта, которым они пользуются сейчас. Справиться с этим помогают качественные и количественные методики, описанные в следующих главах.

Тестирование на этапе исследования продукта в компаниях, не расположенных к риску

О том, как проводить исследование продукта в стартапах, написано много — и мной, и другими авторами. Перед стартапами стоит множество трудных задач, но главная и первоочередная — это выживание.

У стартапов есть преимущество: не приходится тащить за собой груз предыдущих, устаревших версий; у них еще нет дохода, который нужно сохранить, и хорошей репутации, которую необходимо поддерживать. Благодаря этому они идут вперед очень быстро и соглашаются на значительные риски без особых негативных последствий.

Как только ваш продукт развивается до такой степени, что на его продаже можно построить жизнеспособный бизнес (примите мои поздравления!), вам есть что терять. И совсем неудивительно, что теперь придется кое-что изменить в динамике исследования продукта. Я хочу обратить ваше внимание на эти различия и описать, как меняются методики стартапа, когда он вырастает до масштабов крупной корпорации. О применении этих методик в корпорациях писали и другие авторы, но, признаться, их советы не произвели на меня особого впечатления. Чаще всего предлагается сколотить защищенную от рисков команду; обеспечить ее, образно говоря, прикрытием с воздуха, чтобы ее члены могли заниматься инновациями, не опасаясь последствий. Но что при этом подумают сотрудники, которые не входят в состав этих особенных команд? А что будут думать о нынешних продуктах компании? Даже если какая-то идея новаторов кажется весьма перспективной, насколько позитивно, по-вашему, существующие продуктовые команды воспримут эти новые знания? Тут я перечислил лишь несколько из целого ряда причин, по которым я не могу быть сторонником так называемых корпоративных инновационных лабораторий.

Уже не первый год я настаиваю на том, что многие методики исследования продукта и быстрого тестирования и обучения в полной мере применимы в крупных, устоявшихся компаниях, а не только в стартапах. Все лучшие продуктовые компании, такие как Apple, Amazon, Google, Facebook, Netflix, давно и надежно используют этот подход к инновациям. В этих компаниях инновациями разрешено заниматься не только горстке избранных. Это долг и ответственность всех продуктовых команд, которые там работают.

Прежде чем двигаться дальше, хочу еще раз обратить ваше внимание на важнейшее предостережение для технологических компаний: перестанешь внедрять инновации — умрешь! Может быть, это случится не сразу, но если вы только оптимизируете старые решения, полностью отказываясь от инноваций, смерть лишь вопрос времени. Рано или поздно вы непременно станете чьим-нибудь обедом.

На мой взгляд, это не подлежит обсуждению; мы просто обязаны постоянно развивать и улучшать свои продукты, повышая их ценность для потребителей. Но подходить к этому нужно ответственно, а значит, делать две важные вещи: защищать от рисков свой доход и бренд и защищать своих сотрудников и клиентов.

Защищай свой доход и бренд

После того как компания создает себе репутацию и начинает получать доход, работа ее продуктовых команд состоит в проведении исследования продукта таким образом, чтобы защищать репутацию и прибыль от всех возможных рисков. Сегодня в нашем распоряжении есть больше способов, чем раньше, в том числе отличные методики для создания недорогих прототипов с очень низким уровнем риска, которые позволяют проверять, что работает, а что нет, с минимальными инвестициями и ограниченным приобщением к этому участников тестирования. Вот почему мы все просто обожаем прототипы на реальных данных и тестирование А/В.

Конечно, не все подходы рискованны для бренда или дохода, но в таком случае мы должны использовать методики, позволяющие снизить риск. Для этого отлично подходит A/B-тест с участием одного (или меньше) процента клиентов.

Однако иногда приходится быть более консервативными. Тогда проводится тестирование на реальных данных только по приглашению или используется программа определения новых потребителей, в рамках которой к тестированию привлекают лишь пользователей, подписавших соглашение о неразглашении. Есть множество других методик для тестирования в том же духе, которые позволяют компаниям приобретать нужные знания продуманно и ответственно.

Защищай своих сотрудников и потребителей

Помимо защиты доходов и бренда нам также необходимо защищать своих сотрудников и потребителей. Если служба поддержки клиентов, службы профессиональных услуг или торговый персонал вечно пребывают в шоке от калейдоскопа изменений, людям очень трудно выполнять свою работу и заботиться о потребителях качественно и достойно.

Потребители тоже не слишком долго будут оставаться счастливыми, если ваш продукт, по их восприятию, сильно напоминает постоянно движущуюся цель, и у людей создается впечатление, что для того чтобы им пользоваться, нужно постоянно переучиваться.

Вот почему мы используем «мягкие» методы развертывания, в том числе постоянно оцениваем воздействие изменений на потребителя. Может, это выглядит нелогично, но непрерывное развертывание весьма действенная и щадящая методика, и при правильном ее применении в комбинации с оценкой влияния изменений на потребителя это очень мощный инструмент защиты.

Большинство экспериментов и изменений не доставляют никаких проблем, но наша обязанность — относиться к защите потребителей и сотрудников проактивно и оценивать, как скажутся на них те или иные изменения.

Не поймите меня неправильно. Я не утверждаю, что внедрять инновации в корпоративных компаниях легко и просто. Конечно же, это не так. Но не из-за того, что методики исследования продукта этому мешают. Если вы хотите планомерно предлагать потребителям все большую и большую ценность, они необходимы. У крупных корпоративных компаний, как правило, есть проблемы более общего характера, которые обычно и становятся препятствием для инноваций. Если вы работаете в такой компании, знайте: ради непрерывного улучшения продукта следует действовать агрессивно, не ограничиваясь несущественными оптимизациями. Но делать это необходимо так, чтобы защищать от возможных рисков бренд и доход и одновременно своих сотрудников и потребителей.

ГЛАВА 53

КАЧЕСТВЕННЫЕ МЕТОДИКИ ТЕСТИРОВАНИЯ ЦЕННОСТИ

Количественное тестирование показывает, что происходит или, наоборот, не происходит, но оно не способно рассказать, почему и что нужно сделать, чтобы исправить не устраивающее нас положение вещей. Поэтому мы проводим качественное тестирование. Если пользователи и клиенты реагируют на новый продукт не так, как мы ожидали, необходимо как можно детальнее выяснить, в чем дело.

Напомним, что качественное тестирование не относится к способам что-либо подтвердить или в чем-либо убедиться. Для этого используется количественное тестирование. А качественное предназначено для быстрого обучения, приобретения нужных знаний и глубокого изучения ситуации.

Проводя такое тестирование с участием пользователей, вы не получите полного ответа от каждого участника, но каждый пользователь, на котором вы тестируете продукт, даст вам что-то вроде очередного кусочка пазла. И со временем вы соберете и увидите такую часть общей картины, что поймете свою ошибку.

Знаю, это весьма громкое заявление, тем не менее берусь утверждать, что качественное тестирование идей продукта на реальных пользователях и клиентах, по всей вероятности, важнейшая активность в рамках исследования продукта для вас и вашей продуктовой команды. Чрезвычайно важно проводить по крайней мере два-три качественных теста на ценность продукта каждую неделю. Делается это так.

СНАЧАЛА ПРОВЕСТИ ИНТЕРВЬЮ

Обычно пользовательский тест начинается с короткого интервью с пользователем, во время которого нам нужно постараться выяснить, действительно ли у него есть проблемы, которые мы предполагаем; узнать, как он решает их сейчас и что необходимо ему предложить, чтобы он согласился пользоваться нашим продуктом (см. главу 41).

ЮЗАБИЛИТИ-ТЕСТ

Как уже говорилось, сегодня в нашем распоряжении имеется целый ряд хороших методов для качественного тестирования ценности, но все они требуют, чтобы пользователь понимал, что представляет собой ваш продукт и как он работает. По этой причине тестированию ценности продукта всегда должен предшествовать юзабилити-тест.

Во время тестирования юзабилити мы проверяем, может ли человек без особого труда разобраться, как пользоваться тем, что мы ему предлагаем. И что еще важнее, после юзабилити-теста человек должен знать, в чем смысл вашего продукта и как его предполагается использовать. Только тогда мы можем завести с ним разговор о ценности продукта либо ее отсутствии.

Таким образом, подготовка теста на ценность обязательно должна включать в себя подготовку юзабилити-теста. В предыдущей главе я описал, как это делается, а сейчас позволю себе еще раз отметить, что юзабилити-тест важно проводить перед тестированием ценности и проводить их нужно сразу же один за другим.

Если вы попытаетесь провести тестирование ценности, не предоставив пользователю или клиенту возможности узнать, как используется ваш продукт, тест будет больше напоминать фокус-группу, в которой люди обсуждают ваш продукт гипотетически, пытаясь представить себе, как он может работать. Для полной ясности добавлю: методика фокус-групп весьма полезна для понимания рынка, но не поможет нам провести исследование и определить, какой продукт нужно поставить на рынок (см. главу 33).

В этом тестировании должны участвовать как минимум менеджер и дизайнер продукта, но, как уже не раз говорилось, меня не перестает удивлять волшебство, возникающее тогда, когда вместе с вами за ходом тестирования наблюдает еще и инженер-программист. Поверьте, стоит приложить все усилия, чтобы привлечь к этим тестам технарей.

При тестировании юзабилити и ценности пользователь должен иметь возможность использовать один из прототипов, описанных в предыдущих главах. Для тестов на ценность обычно применяются пользовательские прототипы высокой детализации, следовательно, прототип выглядит очень реалистично и воспринимается таким. Как показывает опыт, это чрезвычайно важно для эффективного тестирования ценности. Можно также использовать прототипы на реальных данных или смешанные прототипы.

СПЕЦИАЛИЗИРОВАННЫЕ ТЕСТЫ НА ЦЕННОСТЬ

При тестировании ценности, когда вы сидите лицом к лицу с реальными пользователями и клиентами, возникает такая сложность: поскольку люди в целом любезны и вежливы, им не хочется говорить вам в глаза, что они действительно думают о вашем предложении. Поэтому все тесты на ценность разработаны так, чтобы мы были уверены в том, что пользователь не просто пытался быть с нами милым и добрым.

ДЕНЬГИ КАК СПОСОБ ДЕМОНСТРАЦИИ ЦЕННОСТИ

Один из моих любимых подходов к измерению ценности — это проверка того, готов ли пользователь заплатить за ваш продукт, даже если вы не собираетесь взимать с него плату. Мы ищем человека, готового немедленно вытащить кредитку и попросить нас продать ему наш замечательный новый продукт (на самом деле данные его карты нам не нужны).

Если речь идет о дорогостоящем продукте для корпоративных клиентов, стоимость которого не вписывается в сумму, имеющуюся обычно на потребительской кредитной карте, можно спросить людей, готовы ли они подписать «неформальное намерение» сделать покупку; согласие говорит о том, что собеседники настроены серьезно.

РЕПУТАЦИЯ КАК СПОСОБ ДЕМОНСТРАЦИИ ЦЕННОСТИ

Пользователи могут «заплатить» за продукт и другими способами, скажем собственной репутацией. Для этого вам нужно спросить, насколько велика вероятность, что они порекомендуют его своим друзьям, коллегам или начальству (обычно по шкале от 0 до 10). Можно также попросить их поделиться информацией о нем в социальных сетях или дать вам адрес электронной почты их руководителя или друзей, чтобы вы могли предложить им продукт (даже если вы не станете это делать, чрезвычайно важна готовность человека поделиться контактными данными).

ВРЕМЯ КАК СПОСОБ ДЕМОНСТРАЦИИ ЦЕННОСТИ

Можно также спросить пользователя, готов ли он уделить значительное время совместной работе над новым продуктом (даже если вам это не нужно); такой подход хорош для тестов с корпоративными клиентами. Люди платят за ценность и таким способом.

ПРЕДОСТАВЛЕНИЕ ДОСТУПА КАК СПОСОБ ДЕМОНСТРАЦИИ ЦЕННОСТИ

Вы можете попросить реквизиты доступа к какому-либо продукту, с которого пользователи готовы переключиться на ваш, объяснив это утилитой миграции или другой причиной. На самом деле вам не нужны ни их логин, ни пароль — просто вы хотите знать, ценят ли они ваш продукт настолько высоко, чтобы начать использовать его немедля.

ИТЕРАЦИИ ПРИ РАБОТЕ С ПРОТОТИПОМ

В этом случае ваша цель не что-либо доказать или подтвердить, а быстро и эффективно получить нужные и полезные знания. Вы считаете, что обнаружили новую проблему, либо хотите попробовать иной подход и вам нужно его проверить. Например, вы показали свой прототип двум разным людям, и их отзывы сильно отличаются, попытайтесь выяснить почему. Возможно, это два разных типа клиентов, и у них совершенно разные проблемы. Или это разные типы пользователей со своими навыками или квалификацией в разных предметных областях. А может, они используют различные решения, и один из них доволен продуктом, а второй нет.

Может также оказаться, что вам не удается заинтересовать людей той проблемой, над решением которой вы работаете, или у вас не получится сделать свое предложение удобным и понятным настолько, чтобы целевые потребители осознали его ценность. В этом случае вы, возможно, решите вообще прекратить работу над идеей или отложите ее. Некоторые продакт-менеджеры считают это серьезным провалом. Я же отношусь к такой ситуации как к благоприятной возможности для компании сократить ненужные траты на создание бесперспективного продукта.

Этот вид качественного тестирования замечателен своей простотой и эффективностью. Вы убедитесь в этом, дав свой ноутбук или планшет с установленным на нем продуктом или прототипом человеку, который его еще не видел, и предложив его опробовать.

И одно важное замечание: менеджер продукта должен присутствовать на каждом качественном тестировании ценности. Никогда никому не делегируйте эту обязанность и уж, конечно, не нанимайте для этого стороннюю фирму. Ваш вклад в эффективность своей команды в огромной мере зависит от прямого общения с как можно большим числом пользователей, тесного взаимодействия с ними при тестировании разных идей и внимательного изучения их отзывов. Если бы вы работали в моей компании, это условие было бы главнейшим критерием сохранения вашей фамилии в зарплатной ведомости.

ГЛАВА 54

КОЛИЧЕСТВЕННЫЕ МЕТОДИКИ ТЕСТИРОВАНИЯ ЦЕННОСТИ

Если предназначение качественного тестирования заключается в быстром обучении и составлении новой аналитической картины, то количественные методики — это инструменты для сбора подтверждений ценности ваших идей.

Иногда необходимо собрать достаточно данных для получения статистически достоверных результатов — особенно для потребительских сервисов с большим ежедневным трафиком, — а иногда планка устанавливается ниже. Мы просто собираем фактические данные об использовании продукта, которые считаем полезными подтверждениями его ценности, способными, помимо всего прочего, помочь нам принять обоснованное решение насчет наших дальнейших действий. Это и есть основное предназначение прототипа на реальных данных, который мы обсуждали раньше. Напомним, что такой прототип входит в число создаваемых на этапе исследования продукта для того, чтобы предложить ограниченной группе пользователей определенные сценарии его применения и в итоге собрать некоторые фактические данные об этом.

Существует несколько основных способов сбора таких сведений. Выбор методики зависит от объема вашего трафика, времени и отношения к риску.

У стартапов трафик обычно невелик, да и времени маловато, зато они смело идут на риск — ведь им еще нечего терять. В устоявшейся компании трафика более чем достаточно, и она располагает временем. Причиной для беспокойства обычно бывает то, что у менеджмента может лопнуть терпение. И, как правило, такие компании не склонны рисковать.

A/B-ТЕСТИРОВАНИЕ

Золотым стандартом этого типа тестирования считается A/B-тест. Мы очень любим эти тесты, потому что пользователь не знает, какую версию продукта он видит, и мы получаем данные, весьма надежные с точки зрения точности прогнозирования, к чему мы, собственно, и стремимся.

Имейте в виду: речь идет о немного ином типе A/B-тестов, чем A/B-тесты с целью оптимизации. Во втором случае мы экспериментируем с разными призывами к действию, цветовыми решениями кнопок и тому подобными вещами. Концептуально эти типы тестирования одинаковы, но на практике между ними есть важные различия. В частности, A/B-тесты с целью оптимизации обычно предполагают поверхностные изменения с низким уровнем риска; часто это тесты в рамках сплит-теста (50:50).

В ходе A/B-тестирования на этапе исследования мы демонстрируем продукт 99 процентам пользователей, а прототип на реальных данных — только одному проценту, а то и меньше. И гораздо внимательнее отслеживаем результаты.

ТЕСТИРОВАНИЕ ТОЛЬКО ПО ПРИГЛАШЕНИЮ

Если ваша компания не готова идти на риск или вам не хватает трафика, чтобы продемонстрировать версию продукта одному или даже 10 процентам пользователей и быстро получить значимые результаты, примените такой эффективный метод сбора доказательств, как тест только по приглашению. В этом случае вы определяете группу пользователей или клиентов, с которыми связываетесь и приглашаете испытать новую версию продукта. Вы говорите им, что это экспериментальная версия и, решив запустить ее на своем оборудовании, они дают согласие на участие в тестировании. Получаемые от этой группы данные не так информативны и полезны для прогнозирования, как полученные в результате реального «слепого» А/Б-тестирования. Очевидно, что чаще всего использовать «сырой» продукт соглашаются так называемые ранние последователи — люди, склонные ко всему новому и непривычному. Тем не менее мы получаем группу реальных людей, которые выполняют свою работу с использованием нашего прототипа на реальных данных, и данные, собранные таким образом, действительно очень важны и интересны.

Я даже не могу сосчитать, как часто мы полагаем, будто у нас есть то, что пользователи непременно полюбят, а после того как делаем это доступным для узкой группы людей, обнаруживаем, что их это ничуть не интересует. К сожалению, после проведения количественного теста данного типа мы точно узнаем только одно: что люди упорно этим не пользуются; и ни малейших подсказок и намеков на то, чем объясняется такая ситуация. Поэтому после такого теста проводится тот или иной качественный тест, позволяющий еще раз протестировать идею и максимально быстро узнать, почему пользователи увлечены ею не так сильно, как мы надеялись.

ПРОГРАММА ПО ВЫЯВЛЕНИЮ НОВЫХ ПОТРЕБИТЕЛЕЙ

В одном из вариантов теста только по приглашению к тестированию привлекают участников программы по выявлению новых потребителей, которую мы обсуждали выше, в разделе, посвященном методикам для выработки идей. Эти компании уже принимают участие в тестировании ваших новых версий, и у вас налажены с ними тесные взаимоотношения, благодаря чему можно без труда продолжить с ними сотрудничество.

Обычно я применяю такой подход как основную методику для сбора фактических данных об использовании продуктов для корпоративных клиентов. Участники нашей программы по выявлению новых потребителей часто получают обновления прототипа на реальных данных, и мы сравниваем их данные об использовании с данными более широкого пула клиентов.

Роль аналитики

Одно из самых значительных изменений в нашем сегодняшнем подходе к созданию нового продукта связано с использованием аналитических данных. В наши дни от каждого хорошего продакта ожидают умения работать с такими данными и использовать аналитику для быстрого обучения, приобретения нужных знаний и повышения профессионального уровня.

Я объясняю это изменение несколькими факторами. Во-первых, тем, что благодаря глобальному доступу — и появлению сетевых устройств — рынок наших продуктов в последние годы резко расширился, а объем данных многократно увеличился и несравненно быстрее обеспечивает нас интересными и статистически значимыми результатами.

Во-вторых, тем, что инструменты для получения доступа к этим данным и приобретения благодаря им ценных знаний за последние годы значительно усовершенствовались. Но главную причину я вижу в осознании той роли, которую обычно играют эти данные, помогая вам быстро учиться и адаптироваться к изменениям.

В сильных продуктовых командах мы видим пять основных областей применения аналитических данных. Предлагаю детально рассмотреть каждую из них.

Понимание поведения пользователей и потребителей

Большинство людей, думая об аналитике, имеют в виду именно данные о пользователях продуктов, притом что это только один тип аналитики. Эти данные изучаются для того, чтобы понять, каким образом пользователи и клиенты используют наши продукты (помните: на одного потребителя приходится много пользователей, по крайней мере в контексте «бизнес для бизнеса»). Мы делаем это для выявления функций, которые ими не используются; для подтверждения того, что функции применяются так, как мы того ожидали; или просто для того, чтобы лучше понять, насколько велика пропасть между тем, что люди говорят и что делают.

Успешные продуктовые команды собирают и используют такие аналитические данные с этой целью уже не менее тридцати лет. За доброе десятилетие до появления интернета персональные компьютеры и серверы с помощью превентивного контроля состояния устройств собирали поведенческую аналитику, которая затем изучалась продуктовыми командами для доработки и усовершенствования продукта. По-моему, это одно из очень немногих требований к продукту, которое не стоит даже обсуждать. Я убежден: если вы собираетесь добавить новую фичу, вам необходимо включить как минимум базовый механизм сбора аналитики по ее использованию. А иначе как вы узнаете, работает ли она так, как вам требуется?

Оценка прогресса продукта

Уже много лет я пылкий сторонник использования данных для управления продуктовыми командами. Вместо того чтобы выдавать команде устаревшие дорожные карты» с составленными кем-то списками догадок относительно того, какие фичи могут (или не могут) сработать, я предпочитаю предложить ей набор бизнес-целей с измеримыми конечными результатами, после чего команда сама принимает решение, какими способами лучше всего этих целей достигать. Это один из аспектов всеобъемлющей тенденции, наблюдающейся сегодня в сфере разработки новых продуктов — сосредоточиваться на результате, а не на процессе.

Подтверждение перспективности идей относительно продукта

Сегодня мы — особенно в компаниях по выпуску потребительских товаров, — проводя A/B-тесты, а затем сравнивая полученные результаты, имеем отличную возможность вычленить вклад новых фич, новых версий рабочих процессов и новых проектных решений. Это позволяет получать наглядные подтверждения того, какие из наших идей работают, а какие нет. Нам не нужно делать это со всеми своими предложениями, но для исследования продуктов, сопряженных с серьезным риском или высокими затратами на развертывание, или тех, что требуют изменений поведения пользователей, этот инструмент может быть чрезвычайно действенным и полезным. Даже если сбор статистически значимых результатов существенно затруднен из-за объема трафика или занимает очень много времени, мы имеем возможность собирать фактическую аналитику с помощью прототипов на реальных данных и принимать в итоге более информированные решения.

Сбор информации для принятия решений о продукте

По моему многолетнему опыту, самым скверным в решениях о продуктах в прошлом было то, что они обычно опирались на чьи-то мнения. И как правило, чем более высокую должность занимал в организации этот человек, тем больше с ним считались.

Сегодня, когда мы руководствуемся правилом «данные важнее мнений», у нас есть возможность провести тест и использовать собранные данные для принятия более обоснованных решений. Конечно, аналитика — это еще не все, и мы не должны становиться ее рабами, но в лучших продуктовых командах я вижу бесчисленные примеры удачных решений, в основу которых легли именно результаты тестов. И я постоянно слышу от людей, как часто аналитические данные становятся для них сюрпризом и как сильно меняют их точку зрения.

Вдохновение от работы над продуктом

Я давно укрепился в намерении использовать аналитические данные во всех перечисленных случаях, но, должен признать, мой фаворит — этот последний пункт. Совокупные данные, собранные из всех доступных источников, могут стать для нас настоящей «золотой жилой». Тут часто все сводится к умению задавать правильные вопросы, но впоследствии, изучая эти данные, мы можем выявить некоторые очень большие возможности в плане создания новых продуктов. Лучшие проекты, которые разрабатываются прямо сейчас, были вдохновлены именно аналитикой. Конечно, мы часто получаем отличные идеи, наблюдая за потребителями и применяя новые технологии, но анализ и изучение данных нередко становятся озарением и мощным толчком, дающим старт поистине революционным идеям. Во многом так происходит потому, что аналитика частенько застает нас врасплох, становится сюрпризом. У нас имеется ряд предположений о том, как используется наш продукт, причем о большинстве вариантов мы даже не подозреваем, и, увидев данные, очень удивляемся тому, насколько сильно действительность не соответствует нашим ожиданиям. И такие сюрпризы нередко становятся толчком к реальному прогрессу.

Менеджер по высокотехнологичным продуктам обязан разбираться в разных видах данных для тех продуктов, с которыми он работает. Многие коллеги, надо признать, подходят к этой задаче слишком узко. Вот базовый набор аналитики для работы с большинством высокотехнологичных продуктов.

Аналитика тенденций пользовательского поведения (отслеживание кликов, активность пользователей).

Бизнес-аналитика (активные пользователи, коэффициент конверсии, пожизненная ценность клиента, коэффициент удержания клиентов).

Финансовая аналитика (средняя продажная цена, обороты по счетам, время закрытия счетов).

Производительность (время загрузки, аптайм).

Операционные расходы (хранение, хостинг).

Затраты, связанные с выходом на рынок (логистические затраты, себестоимость продаж, маркетинговые программы).

Структура поведения (индекс потребительской лояльности [Net Promoter Score, NPS], уровень удовлетворенности потребителей, опросы).

Надеюсь, теперь вы видите, какую огромную роль играет аналитика в успехе продуктовых команд. Однако, как бы ни были важны и полезны эти данные, важно помнить, что они проливают свет на происходящее, но не объясняют причин. Для интерпретации количественных результатов нам необходимы качественные методики.

(Обратите внимание: аналитические данные часто используются для отслеживания ключевых показателей эффективности [key performance indicators, KPI]).

Работа вслепую

Как ни удивительно, я и сегодня сталкиваюсь с продуктовыми командами, которые либо не используют свой продукт для сбора аналитических данных, либо так мало занимаются этим, что все равно не знают, использовался ли их продукт, и если да, то как.

Мои команды — и каждая команда, которую я могу вспомнить из тех, с какими когда-либо работал, — делают это так давно, что нам даже трудно представить, как можно работать без этой ценной информации. Я даже не могу вспомнить, каково это — не иметь ни малейшего представления о том, как использовался тот или иной продукт, какие фичи помогают пользователю решить его проблемы и те ли это фичи, которые, на наш взгляд, необходимо предложить, чтобы продукт охотно покупали.

Проще всего это делать с помощью «облачных» продуктов и сервисов, и большинство из нас используют веб-аналитику, но иногда мы выбираем для этого собственные инструменты.

Как я уже говорил, хорошие продуктовые команды занимаются сбором аналитики о своих продуктах не один год. И не только с помощью «облачных» сайтов, но и с использованием установленных мобильных приложений или приложений для ПК — локального софта, оборудования и устройств, которые периодически проводят проверку и отправляют командам данные о фактическом использовании их продуктов. Нужно сказать, очень немногие компании сегодня настолько консервативны, чтобы запрашивать разрешение перед отправкой этих данных; в основном все проходит, так сказать, без лишних слов.

Безусловно, надо анонимизировать данные и агрегировать их так, чтобы в них не было никаких сведений, по которым можно установить личность их автора. И все же время от времени в новостях рассказывают о компаниях, которые нажили большие проблемы из-за того, что в своем стремлении выйти на рынок рассылали «сырые» данные. Создается впечатление, что, по мнению журналистов, мы отслеживаем их ради корыстных, гнусных целей, но все компании, с которыми я знаком, просто стараются выпускать лучшие продукты — более ценные, удобные и полезные для людей. А сбор аналитических данных уже давно стал в этом одним из важнейших инструментов.

В общем все происходит так: сначала мы задаем себе вопрос, что нам нужно знать об использовании наших продуктов, затем дополняем продукт возможностями для сбора этой информации (выбор методик зависит от используемого инструмента и от того, какие данные нам нужны). И в конце генерируем онлайн-отчеты в различных формах для анализа собранных данных и их интерпретации.

Мы стремимся располагать инструментами для оценки всего нового, что добавляется в продукт, чтобы незамедлительно узнавать, работает ли он так, как мы ожидаем, и не возникло ли не предусмотренных нами последствий. Честно говоря, без этого инструментария я не стал бы выводить на рынок ни одну новую фичу. Откуда нам знать, как она в действительности работает?

Большинство успешных менеджеров продукта первым делом утром проверяют аналитику, чтобы узнать, что произошло за предыдущую ночь. Они постоянно проводят тестирование в той или иной форме, и им, разумеется, очень интересно, что эти тесты показывают.

Конечно, существуют экстремальные среды, где все происходящее защищено надежнейшими брандмауэрами, но даже в этом случае продакты могут генерировать периодические отчеты об их использовании; эти отчеты анализируются и после получения разрешения направляются продуктовым командам (при необходимости в виде электронных или печатных документов).

Я большой энтузиаст радикального упрощения продуктов путем удаления из них всех функций и опций, которые не способны нести даже свой вес. Но если не знаешь, что и как используется, это становится весьма мучительным, ведь неизвестно, что происходит на самом деле. В этом случае у нас нет данных, которые подтверждали бы наши теории или решения, и наш менеджмент (с полным на то правом) артачится, не желая их принимать.

На мой взгляд, вам стоит начать с признания того, что наличие аналитических данных о продукте обязательно, и стартовать отсюда в обратном направлении, чтобы найти лучший способ их получения.

ГЛАВА 55

ТЕСТИРОВАНИЕ РЕАЛИЗУЕМОСТИ

Для того чтобы подтвердить наличие технических возможностей идеи, инженеры-программисты стараются ответить на ряд вопросов по существу дела:

Знаем ли мы, как это создать?

Обладает ли наша команда необходимыми для этого навыками?

Достаточно ли у нас времени для создания продукта?

Потребуются ли какие-либо изменения архитектуры?

В наличии ли все необходимые компоненты?

Понимаем ли мы, какие взаимосвязи и зависимости предполагает реализация идеи?

Будет ли приемлемой производительность полученного результата?

Будет ли полученный результат масштабироваться до необходимого уровня?

Имеется ли у нас инфраструктура для его тестирования и запуска?

Можем ли мы позволить себе все связанные с этим расходы?

Я не намерен вас пугать. В большинстве случаев ваши разработчики, оценивая идеи новых продуктов на этапе исследования, быстро рассмотрят все эти пункты и ответят, что проблем нет. По большому счету задачи не такие уж и новые, и разработчики уже много раза делали что-то подобное.

Тем не менее к некоторым идеям это не относится, и тогда ответить на эти или даже на многие из перечисленных вопросов бывает очень трудно.

Приведу весьма распространенный пример: сегодня многие команды оценивают технологию машинного обучения, обдумывают решения типа «создавать или покупать» и прикидывают, подходит ли она для выполняемой ими задачи — и, если говорить шире, пытаются оценить ее потенциал.

С удовольствием дам вам несколько важных практических советов на этот счет. Проведение еженедельных планерок, на которых менеджер продукта, предлагая инженерам-программистам готовый список идей, требует дать их оценку с точки зрения затрат времени, насчитать баллы за пользовательскую историю или оценить в других единицах усилий, которые понадобятся для ее реализации, — это верный рецепт краха. Если вы припрете разработчика к стене, не дав ему времени расследовать и обдумать идею, то, скорее всего, получите от него консервативный ответ, нацеленный отчасти на то, чтобы его оставили в покое. Если же ваши инженеры-программисты вместе с другими членами команды тестировали идеи на потребителях (с применением прототипов) и своими глазами видели их проблемы и то, как они отнеслись к этим идеям, значит, у них, по всей вероятности, уже было некоторое время на их обдумывание. Короче говоря, если вы считаете идею стоящей, дайте специалистам возможность изучить и проанализировать ее.

Не следует ставить вопрос так: «Ну что, сможете это сделать?» Попросите инженеров-программистов ознакомиться с идеей и ответить на вопрос: «Как, по-вашему, это лучше сделать, и сколько времени это займет?».

Иногда чуть позже они возвращаются к менеджеру со словами, что для того, чтобы ответить на один или несколько из перечисленных вопросов, им нужно создать прототип для проверки реализуемости замысла. В таком случае сначала обдумайте, заслуживает ли потенциал идеи столь существенных трат времени на этапе исследования. И если да, давайте добро на дальнейшую работу.

И последнее важное замечание об оценке осуществимости новых идей: я не раз встречал и до сих пор встречаю менеджеров продукта, которым ненавистна любая идея, если на ее обдумывание инженеры-программисты просят дать им время. Этим менеджерам такой ответ говорит о том, что идея рискованная и на ее реализацию уйдет слишком много времени (в лучшем случае). Обычно я им говорю, что мне такая ситуация, напротив, очень нравится по нескольким причинам. Во-первых, многие удачные идеи относительно продуктов основываются на таких подходах к решению, которые стало возможным применять только сейчас, что означает появление новой технологии, на изучение которой людям нужно время. Во-вторых, по моему опыту, если технарям дают хотя бы два дня на изучение и обдумывание идеи, они часто возвращаются не только с хорошими ответами на вопросы о возможностях ее реализации, но и с более перспективными способами решения проблемы. В-третьих, такой подход обычно очень мотивирует команду, поскольку обеспечивает людей возможностью учиться и проявлять свои таланты и способности.

Этап исследования для аппаратных продуктов

Как известно, сегодня очень многие высокотехнологичные продукты включают в себя аппаратный элемент. Телефоны и часы, робототехника и автомобили, медицинская аппаратура и термостаты — смарт-устройства повсюду. Каким образом включение в уравнение аппаратных средств влияет на все, что мы с вами к этому моменту обсудили?

Некоторые различия в подходах очевидны, например, необходимы другие инженерно-технические навыки, потребность в промышленном дизайне. И конечно, на производство «железа» по-прежнему уходит значительно больше времени, чем на написание софта, хотя, нужно признать, тут ситуация постоянно улучшается.

По большей части все, что мы с вами обсудили, применимо и к аппаратным продуктам, хоть есть и дополнительные вызовы. Скажу больше: когда в уравнение включается аппаратное обеспечение, методики исследования продукта, о которых мы говорили в предыдущих главах, приобретают большое значение, и в первую очередь это касается прототипирования. При разработке «железа» ошибки обходятся гораздо дороже и в сроках, и в деньгах. При работе над софтом исправление ситуации стоит относительно недорого, а с аппаратными продуктами все не так просто. В частности, создание «железа» сопряжено со значительно большими рисками технической осуществимости; возникают дополнительные риски и в связи с бизнес-жизнеспособностью решения. Например, для аппаратного обеспечения требуется более сложный анализ компонентов и производственных затрат и такое же прогнозирование. Хотя, нужно признать, в последние годы процедура прототипирования аппаратных средств усовершенствовалась и упростилась благодаря появлению технологии 3D-печати.

И главное, аппаратные продукты требуют от разработчиков агрессивного подхода к работе с рисками ценности, юзабилити, реализуемости и бизнес-жизнеспособности, а еще приходится намного выше поднимать планку веры в успех продукта, прежде чем браться за его изготовление.

ГЛАВА 56

ТЕСТИРОВАНИЕ БИЗНЕС-ЖИЗНЕСПОСОБНОСТИ

Никто не станет спорить с тем, что даже просто попытаться придумать продукт, который полюбят потребители, а инженеры-программисты сумеют создать и поставить на рынок, чрезвычайно трудно. Многие идеи никогда не доходят до этого момента. Но и этого недостаточно. Решение должно работать и для вашего бизнеса. Словом, я хочу вас сразу предупредить, что выполнить это требование намного сложнее, чем кажется на первый взгляд.

Многие продакт-менеджеры признаются, что это самая нелюбимая часть их работы. Я отлично их понимаю, но объясняю, что именно это умение часто отличает хорошего продакта от великого и его в первую очередь имеют в виду, когда говорят о ком-то как о СЕО по продукту.

Создание бизнеса всегда дело сложное. Вам необходимо иметь жизнеспособную бизнес-модель. Затраты на производство, маркетинг и продажу продукта должны быть существенно ниже приносимого им дохода. Вы должны действовать с соблюдением законодательства всех стран, в которых продаете свой продукт. И неуклонно соблюдать свои обязанности в рамках всех деловых и партнерских соглашений. При этом каждый ваш продукт должен органично вписываться в обещание бренда остальных предложений компании.

Вы должны защищать доход, репутацию, сотрудников и клиентов своей компании — все, над достижением чего много и упорно трудились.

В этой главе я назову основные заинтересованные стороны компаний по выпуску высокотехнологичных продуктов, покажу типичные для них тревоги и ограничения, а также объясню, как менеджер продукта тестирует его бизнес-жизнеспособность в каждом из этих аспектов. Отмечу, что это очень общий список и большинство (или все) включенных в него областей, скорее всего, относятся и к вашим продуктам, но нужно помнить, что очень часто в компаниях есть также одна или несколько специфических заинтересованных сторон, уникальных для бизнеса. И то, что они не упомянуты мной далее, не означает, что на мнение такой заинтересованной стороны можно обращать меньше внимания.

Продакт-менеджеру вряд ли хочется столкнуться с ситуацией, когда его команда, усердно трудившаяся и тратившая время на превращение идеи в подходящий для продажи продукт, в итоге узнает, что его нельзя вывести на рынок и предложить потребителю, так как в нем не учтено важное ограничение. Знайте: подобное случается всегда по вине продакт-менеджера, поскольку его обязанность — знать и понимать все важные требования и ограничения и целенаправленно работать над их неукоснительным соблюдением.

МАРКЕТИНГ

Мы уже обсуждали функции маркетинга продукта и говорили о том, что считаем маркетолога скорее членом продуктовой команды, чем заинтересованной стороной. Но в более широком смысле это функциональное подразделение заботится о стимулировании продаж, бренде, репутации и конкурентоспособности компании на рынке, четкой дифференциации продукта. Маркетологам нужно, чтобы итоговый продукт был актуальным и привлекательным для потребителя, чтобы он максимально точно соответствовал используемым компанией каналам выхода на рынок. Следовательно, все ваши мысли и идеи, сопряженные с риском для вышеперечисленного, будут вызывать у отдела маркетинга серьезное беспокойство и даже неприятие.

Если предлагаемая вами идея может как-то сказаться на канале продаж или основных маркетинговых программах либо не согласуется с обещанием бренда (не входит в диапазон ожиданий потребителей от вашей компании), непременно обсудите ее с маркетологами — а лучше покажите им прототипы, — прежде чем приступать к ее реализации. Трудитесь сообща, вместе ищите пути устранения всего, что вызывает у них сомнение и беспокойство.

ПРОДАЖИ

Наличие в вашей компании подразделения прямых продаж или отдела рекламы сильно сказывается на деятельности разработчиков новых продуктов. Как известно, успешны обычно те продукты, которые создаются с учетом преимуществ и ограничений имеющегося у компании канала продаж. Если канал прямых продаж обходится очень дорого, значит, вам нужен продукт с высокой ценностью и высоким ценовым ориентиром. Предположим, вы создали канал продаж с определенными навыками, и если новый продукт требует совсем других умений и знаний, торговый персонал может наотрез отказаться с ним работать.

Словом, если ваша идея сопряжена с существенными отклонениями от продукта, эффективность продаж которого вашим каналом продаж уже доказана, сядьте рядом с руководителями подразделения и продемонстрируйте им свое предложение. Постарайтесь вместе найти эффективный способ продаж. И сделайте все это до того, как приступите к разработке.

УПРАВЛЕНИЕ УСПЕХОМ КЛИЕНТА

В одних компаниях по выпуску высокотехнологичных продуктов реализуется модель персонализированной помощи клиентам (помощи вручную), в других предоставляется автоматизированная помощь. Менеджеру по продукту необходимо хорошо понимать, какая стратегия успеха клиентов используется в вашей компании, и обеспечить согласованность продуктов с ней.

Если вы предлагаете что-то, что потребует серьезных изменений, вам нужно обсудить варианты и альтернативы с руководством этого подразделения.

И еще, при использовании модели персонализированного сервиса его персонал просто незаменим при выработке идей продукта и их тестировании с применением прототипов.

ФИНАНСЫ

Финансовое подразделение, как известно, часто налагает строгие ограничения и высказывает сомнения насчет денежных затрат, и не в последнюю очередь они касаются того, может ли компания позволить себе создание, продажу нового продукта и управление им. Бизнес-аналитика и отчетность тоже прерогатива финансистов, да и отношения с инвесторами и другие сложные вопросы также ставят ограничения.

При возникновении проблем с предстоящими затратами смоделируйте вместе со специалистом из финансового подразделения расходы, чтобы потом продемонстрировать руководству жизнеспособность вашего подхода для бизнеса.

ЮРИДИЧЕСКИЕ АСПЕКТЫ

Во многих высокотехнологичных компаниях, особенно в тех, которые настроены революционно и очень агрессивно, роль юридического департамента чрезвычайно важна. Вопросы безопасности и конфиденциальности, соблюдение законодательств разных стран и прав интеллектуальной собственности, проблемы конкуренции — все это правовые требования, которые касаются любой компании из сферы высоких технологий. И вы сэкономите массу времени и избавитесь от серьезных неприятностей, если как можно раньше обсудите со своими юристами идею, чтобы узнать, не возникнет ли в связи с ее реализацией правовых коллизий, а также уточните разные юридические моменты, которые вам непременно нужно в связи с этим знать.

РАЗВИТИЕ БИЗНЕСА

Как известно, большинство современных компаний поддерживают деловые отношения с разными партнерами; обычно эти отношения скрепляются контрактами с определенными обязательствами сторон. Бывает, эти соглашения снижают конкурентоспособность компании. А иногда, напротив, становятся для нее неоценимым подспорьем. В любом случае вам необходимо понимать влияние этих отношений на ваши продукты и на то, чем вы предлагаете заниматься своей команде в ближайшее время.

БЕЗОПАСНОСТЬ

Обычно к тем, кто занимается вопросами безопасности в компании, мы относимся не как к заинтересованной стороне, а как к неотъемлемой части инженерно-технического подразделения и, следовательно, нашей продуктовой команды. Однако эти вопросы настолько важны, что, на мой взгляд, перед тем как приступать к работе над новой идеей, всегда стоит поговорить с людьми из этой сферы деятельности. В общем, если вы предлагаете что-то, хотя бы отдаленно касающееся проблем безопасности, пусть один из технических руководителей обсудит с руководителем отдела безопасности вашу идею и то, как вы будете решать соответствующие проблемы.

СЕО, ОПЕРАЦИОННЫЙ ДИРЕКТОР И ГЛАВНЫЙ МЕНЕДЖЕР

В каждой компании есть СЕО или главный менеджер, отвечающий за эту бизнес-единицу. Скорее всего, они отлично знают и понимают все описанные выше ограничения и уделяют им должное внимание. И если продакт-менеджер не разбирается в этих вопросах или не имеет плана работы с ними, руководитель компании вряд ли будет доверять ему и его продуктовой команде. Заметьте, СЕО не понадобится много времени, чтобы выяснить, сделал ли менеджер продукта «домашнюю работу» — понимает ли разные аспекты бизнеса.

Тестирование бизнес-жизнеспособности новой идеи или продукта призвано подтвердить, что в предлагаемом командой решении учтены все описанные ограничения. Всем заинтересованным лицам, которых тем или иным образом оно затронет, важно иметь возможность проанализировать новое решение и убедиться, что вы продумали все и нашли способ развеять их сомнения.

Что выбрать — пользовательский тест, демонстрацию продукта или сквозной просмотр?

В этой книге я много говорил о показе прототипа. По правде говоря, эта задача может выполняться с помощью трех разных методов, и нужно очень внимательно выбрать правильный в той или иной ситуации.

Пользовательский тест — это тестирование идеи на реальных пользователях и клиентах. Это качественная методика тестирования юзабилити и ценности; пользователю позволяется делать все собственноручно. Цель — протестировать юзабилити и ценность прототипа или продукта.

Демонстрация продукта — это продажа продукта потенциальным пользователям и клиентам либо проведение мероприятий в духе евангелизма и продвижение продукта в собственной компании. Это инструмент продаж или убеждения. Нужно сказать, что демоверсию с тщательно продуманным сценарием разрабатывают маркетологи, но провести ее иногда просят продакт-менеджера — особенно для важного клиента или высшего руководства компании. В этом случае все действия совершает менеджер продукта, а его цель — продемонстрировать ценность прототипа или продукта.

Сквозной просмотр, или разбор программы, — это показ прототипа заинтересованной стороне, чтобы убедиться, что она обратила внимание на все, что может вызвать у нее беспокойство. В данном случае наша цель — предоставить заинтересованной стороне возможность обнаружить проблему. Все действия обычно выполняет менеджер продукта, но если заинтересованной стороне хочется «поиграть» с прототипом, то ей это с радостью позволяют. Вы не стараетесь что-либо продать, не пытаетесь протестировать продукт и определенно не собираетесь что-либо скрыть и утаить.

Я много раз видел, как неопытные продакт-менеджеры проводят сквозной просмотр с потенциальным клиентом, хотя им следовало бы подготовить демонстрацию продукта. Другая весьма распространенная ошибка новичков — провести демонстрацию в рамках пользовательского теста, а затем попросить пользователя высказать свое мнение.

Всегда четко определяйте, что вы делаете — проводите пользовательский тест, демонстрацию продукта или сквозной просмотр. И непременно убедитесь, что хорошо владеете всеми тремя методиками.

ГЛАВА 57

ЗНАКОМЬТЕСЬ: КЕЙТ АРНОЛЬД ИЗ NETFLIX

Netflix — один из моих любимых продуктов, и одна из моих любимейших компаний. Но мало кто помнит, что в 1999 году совсем еще юная Netflix (тогда она располагалась в Лос-Гатосе, и в ней работало менее двух десятков сотрудников) оказалась на грани разорения. У компании было несколько опытных основателей, в том числе легендарный Рид Хастингс, однако она забуксовала на 300 тысячах клиентов.

В сущности, Netflix предлагала общепринятый подход «плата за прокат», как и Blockbuster, только в онлайн-версии. И у нее, как и у многих, имелась группа ранних последователей, причем некоторые из них жили в местах, где не было ни одного видеомагазина. Согласитесь, мало кто будет брать напрокат DVD через Почтовую службу США, если по дороге домой можно заскочить в местный Blockbuster. Как правило, люди брали видео в Netflix раз или два, после чего быстро забывали об этом сервисе. Похоже, им не слишком хотелось что-нибудь менять. Команда Netflix понимала, что недостаточно опережает конкурентов, чтобы переманить людей на свою сторону.

А тут еще продажи DVD начали неуклонно снижаться, да и противодействие Голливуда усугубляло плохое положение вещей. Не следует забывать и о серьезных трудностях с логистикой, сложностях поддержания высокого качества DVD и попытках понять, как сделать все так, чтобы покрывать расходы и получать прибыль наличными.

Кейт Арнольд была в то время менеджером по продукту этой небольшой команды, и команда точно знала, что нужно что-то менять.

Среди множества предпринятых ими попыток был переход на абонентское обслуживание. По замыслу, нужно было убедить людей подписаться на месяц и предложить абонентам неограниченное количество фильмов. Но вот вопрос: воспримут ли люди это как улучшение и изменят ли свое поведение в сфере медиапотребления?

Хорошей новостью оказалось то, что новый подход понравился потребителям. Фиксированная ежемесячная плата за неограниченный доступ к видео очень заинтересовали их. Но была и плохая новость: таким шагом команда создавала себе реальные трудности. Разумеется, клиенты Netflix хотели смотреть в основном последние художественные фильмы, а такой контент обходился компании дороже всего. Чтобы иметь в наличии необходимое количество копий, требовалось много денег, а их у Netflix не было.

Итак, компании предстояло решить задачу: как, не обанкротившись, сделать так, чтобы клиенты могли смотреть те фильмы, которые хотят?

Команда, перед которой она была поставлена, знала, что нужно каким-то образом убедить клиентов захотеть смотреть микс из дорогостоящих и менее дорогостоящих фильмов. Острая нужда, как известно, мать всех изобретений и нововведений; на этой почве выросли списки ожидания, рейтинговая система и рекомендательный сервис Netflix. Благодаря этим технологическим инновациям появилась новая, более эффективная бизнес-модель.

Команда взялась за дело. За три месяца она изменила дизайн сайта, дополнив абонентское обслуживание Netflix перечисленными выше элементами. А еще она переписала автоматизированную систему расчета с абонентами для работы по модели ежемесячной подписки. (Любопытный факт: начинала компания без этой системы, потому что сперва предлагала тридцатидневный бесплатный пробный период, что обеспечило ее необходимым дополнительным временем.)

Учитывая огромный объем одновременно внедряемых изменений и взаимосвязанных усилий, в процесс были вовлечены почти все сотрудники компании.

Можно представить, какую нагрузку ежедневно несла на своих плечах Кейт: это и работа с соучредителями над выработкой стратегии, и тестирование новой концепции на реальных пользователях, и анализ данных, и разработка фич и функциональности новой системы в составе своей продуктовой команды. Помимо того, вместе с финансистами она трудилась над созданием новой бизнес-модели, с маркетологами — над вопросами закупок, с руководством складов — над реальными проблемами логистики. И все же команда сумела запустить сервис и использовала его для поддержания и развития бизнеса еще семь лет, до тех пор, пока опять не перевернула все с ног на голову, начав решительный и агрессивный переход на модель потоковой передачи.

Кейт, я уверен, приписала бы все заслуги своей потрясающей команде, в том числе некоторым превосходным инженерам-программистам, а также смелому видению и мужеству основателей компании. Но я считаю, что без самой Кейт и ее страсти к высокотехнологичным решениям, которая смогла привести в движение всю компанию, очень даже вероятно, что Netflix в том виде, в каком мы ее сегодня знаем, не состоялась бы.

Еще пара интересных фактов о юной Netflix: на раннем этапе компания столкнулась с серьезной проблемой наличных средств, и тогда она предложила купить себя Blockbuster за 50 миллионов долларов, но та отказалась. Сегодня на Blockbuster никто не поставит и копейки, а Netflix стоит больше 40 миллиардов долларов.

Кейт сегодня работает лидером продукта в Нью-Йорке.

МЕТОДИКИ ДЛЯ ПРЕОБРАЗОВАНИЙ

ОБЗОР

До сих пор мы обсуждали методики исследования продуктов. Надо отметить, что заставить продуктовые команды и компании применять их на практике и работать иначе — это совсем другая задача, выполнить которую очень сложно. Отчасти это объясняется просто человеческой природой, но в первую очередь необходимостью менять организационную культуру.

Приведу в высшей степени наглядный пример. Превратить команды «наемников», использующих дорожные карты продуктов и ориентированных на процесс, в по-настоящему вдохновленные, наделенные широкими полномочиями и ответственные продуктовые команды, которые измеряют свои достижения по конечным бизнес-результатам, — это огромный культурный сдвиг, который требует от менеджмента передачи значительной части своей власти и контроля этим людям. Такие изменения не происходят легко и просто, уж поверьте!

К счастью, в нашем распоряжении есть методики, весьма эффективно помогающие преодолеть все преграды.

ГЛАВА 58

СПРИНТ НА ЭТАПЕ ИССЛЕДОВАНИЯ ПРОДУКТА

Судя по моему опыту, многие команды, особенно те, что только начинают знакомиться с современными методами разработки продуктов, находятся в поиске структурированного введения в современное исследование продукта. В этой главе я опишу спринт на этапе исследования.

Спринт на этапе исследования продукта — это недельный интервал в ходе исследования, в течение которого вам предстоит решить важную проблему или снизить риск, с которым в настоящий момент столкнулась команда. Безусловно, такой метод полезен не только для введения преобразований в командах и компаниях, его можно считать отличным инструментом планирования или прототипирования на этапе исследования. Но, по моему убеждению, полезнее всего объединить все эти способы применения, поэтому я и решил поговорить об этом здесь.

Некоторые специалисты используют термин дизайн-спринт, а не спринт-исследование, но, поскольку цель этой деятельности — при условии, что все сделано как надо, — выходит за рамки дизайна, я предпочитаю использовать обобщающий термин.

Если у вашей компании возникают трудности с использованием минимально жизнеспособного продукта (MVP), то спринт позволит вам начать извлекать ценность из этой важнейшей методики.

С командой Google Ventures (GV) я познакомился много лет назад, в самом начале ее деятельности. Команда входит в инвестиционное подразделение Google и снабжает деньгами стартапы, но гораздо больше она помогает им тем, что обучает правильно подходить к разработке продуктов. В рамках используемой в GV модели ее сотрудники обычно проводят в стартапе неделю: засучив рукава, они показывают своим подопечным, как нужно исследовать продукт, бок о бок с ними выполняя все необходимые действия. (Я знаком с несколькими надежными людьми из этой сферы, работающими индивидуально; они коучи по исследованию продукта и делают для команд то же самое.) За неделю такой интенсивной работы вы со своей командой изучите и проанализируете десятки различных идей и подходов, чтобы решить ту или иную бизнес-задачу. Заканчивается неделя проверкой потенциального решения на реальных пользователях и клиентах. И, как показывает мой опыт, результатом неизменно становится последовательное и очень важное обучение и более глубокое понимание дела; эти знания могут в корне изменить дальнейший курс развития продукта и даже всей компании.

В рамках описанной общей структуры коучи по исследованию продукта пропагандируют множество методик в помощь продуктовой команде, чтобы она прошла весь процесс работы над продуктом и приобрела важные новые знания всего за пять дней.

Поработав с более чем сотней продуктовых команд и на практике отточив свои методы и определив эффективнейшие из них, команда GV решила поделиться этими знаниями в книге Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days15. Ее авторы Джейк Кнапп, Джон Зерацки и Браден Ковиц.

В книге описана типичная пятидневка. Все начинается с формулировки проблемы путем определения области ее решения, выбора проблемы и целевого клиента, после чего используются несколько разных подходов к ее решению. Далее команда сужает фокус и конкретизирует потенциальные решения, затем создается пользовательский прототип с высокой степенью детализации, и наконец его представляют реальным целевым пользователям, наблюдая за их реакцией. И разумеется, все это делается за неделю — даже за пять дней.

В упомянутой книге описаны любимые методики авторов для преодоления каждого из этапов, и если вы все еще читаете мою книгу, то без труда их узнаете. Больше всего эта книга нравится мне тем, что на ее трехстах страницах представлен пошаговый рецепт (с десятками примеров отличных продуктов и команд — вы их тоже непременно узнаете), который, насколько мне известно, желают иметь все команды, начинающие заниматься этой работой. Эту книгу должен прочитать каждый продакт-менеджер, и я советую вам сделать это как можно скорее.

В нескольких ситуациях, начиная с больших задач и проблем, которые команде очень важно и (или) трудно решить, я настоятельно рекомендую использовать спринт на этапе исследования продукта. Эта методика также полезна тогда, когда команда только учится проводить исследование или когда очевидно, что все движется слишком медленно и команде необходимо ускорить темп.

Коучи по исследованию продукта

По мере перехода команд к использованию agile-методов (обычно они начинают с управления проектами Scrum) многие компании решили подписать контракт или нанять agile-коуча. Эти специалисты помогают командам — особенно инженерам-программистам, контролерам качества, продакт-менеджерам и дизайнерам продукта — обучаться методам и образу мышления, без которых применение agile-методологии невозможно.

К сожалению, такое обучение порождает множество проблем, поскольку большинство этих agile-коучей не имеют опыта работы с компаниями по выпуску технологичных продуктов — их опыт ограничивается поставкой продукта на рынок. Следовательно, было бы правильнее называть их agile-коучами по поставке. Они отлично разбираются в инженерно-техническом аспекте разработки новых продуктов и релизах, но не в исследовании продукта.

С этой проблемой столкнулось так много компаний, что вскоре всем стала очевидна острая нужда в коучах с большим опытом работы в компаниях по выпуску технологичных продуктов и в исполнении ключевых ролей, связанных с разработкой новых продуктов, особенно в сфере менеджмента и дизайна продукта. Сегодня таких специалистов часто называют коучами по исследованию продукта.

Коучи по исследованию продукта, как правило, бывшие менеджеры или дизайнеры продукта; они имеют опыт работы или тесного сотрудничества с ведущими компаниями по производству технологичных продуктов. Иными словами, они умеют работать в тандеме с реальными продакт-менеджерами и дизайнерами, а не просто повторять уже практически всем известные факты о методологии Agile и показывать команде, как нужно работать, чтобы работать эффективно.

У каждого такого коуча есть свой любимый способ взаимодействия с командой; обычно в течение недели или около того они занимаются одной или двумя продуктовыми командами. За это время они помогают ее членам пройти от начала до конца один или несколько циклов выработки идей на этапе исследования; создают вместе с ними прототипы и проверяют их на пользователях, чтобы оценить их реакцию; на инженерах, чтобы подтвердить техническую выполнимость идей; на заинтересованных лицах в компании, чтобы определить, будет ли решение выгодным для этого бизнеса.

Признаться, мне трудно представить эффективного коуча по исследованию продукта, не имеющего опыта работы менеджером продукта или дизайнером продукта в современной продуктовой компании. Вероятно, это одна из главных причин того, почему нам сегодня остро не хватает таких специалистов. Кроме того, очень важно, чтобы коуч по исследованию продукта знал, как включить в это уравнение инженеров-программистов. Ему следует с трезвым расчетом подходить к их времени, но понимать, какую огромную роль они играют в инновациях.

Коучи по исследованию продукта чем-то напоминают lean startup-коучей (коучей по вопросам бережливых стартапов). Различие между ними заключается в том, что вторые часто сосредоточивают свои усилия на помощи команде не только в исследовании продукта, но и в разработке бизнес-модели, а также стратегии продаж и маркетинга. После того как молодая компания завоевывает некоторую популярность, ее деятельность по исследованию продукта больше касается непрерывных улучшений уже существующего продукта, а не создания принципиально нового направления бизнеса. По этой причине многие lean startup-коучи не имеют необходимого опыта в области разработки новых продуктов. На мой же взгляд, исследование продукта — важнейшая компетенция любого нового стартапа, поэтому я убежден, что эффективный lean startup-коуч непременно должен быть силен и в этом.

ГЛАВА 59

ПИЛОТНЫЕ КОМАНДЫ

Ранее я уже упоминал о кривой внедрения технологий и говорил о том, что, согласно этой теории, разные люди принимают перемены по-разному. Оказывается, то же самое свойственно и нашим организациям, в частности по отношению к изменению подхода к работе.

Одни сотрудники компании или подразделения ждут перемен с нетерпением; другие предпочитают сначала увидеть пример успешного использования нововведения своими глазами; третьим просто нужно больше времени, чтобы «переварить» новшества; четвертые от природы ненавидят что-либо менять и делают это только вынужденно. Если вы очень решительно и радикально меняете что-то сразу для всех, то отстающие (те самые четвертые) гарантированно будут сопротивляться или даже саботировать ваши старания.

Вместо того чтобы бороться с неприятной реальностью, мы можем ее понять и принять. Облегчает переход компании к новым способам работы метод пилотных команд.

Пилотные команды позволяют внедрять изменения в ограниченной части организации и, образно говоря, «откатывать» их, прежде чем они распространятся на всю компанию. Однако для этого вам придется найти продуктовую команду, которая добровольно испытает новые методики. Вы позволяете ее членам некоторое время (один или два квартала) использовать новый способ и наблюдаете за тем, как идут дела.

Используемые критерии успеха зависят от ваших целей, но в конечном счете вы должны оценить эффективность пилотной команды в обеспечении бизнес-результатов, то есть узнать, насколько успешнее она достигает поставленных целей по сравнению с другими командами или собственными показателями в прошлом. Конечно же, учитывая природу эксперимента, такая оценка будет носить качественный характер, но это не умаляет ее важности и убедительности.

Если дела в пилотной команде идут хорошо, скорее всего, со временем найдется еще несколько команд, готовых попробовать новые способы работы. В противном случае вы можете решить, что это вам не подходит или требует внести коррективы.

Чтобы повысить шансы пилотных команд на хороший результат, следует тщательно отбирать в них людей, а также продумывать, где они будут работать и насколько широкие полномочия им будут предоставлены. В идеале нужно стремиться к тому, чтобы это были сотрудники более других склонные к переменам и новым способам работы; чтобы ключевые игроки трудились рука об руку, а команда в значительной степени контролировала свою работу и не слишком сильно зависела от команд, все еще работающих по старинке.

ГЛАВА 60

ОТКАЗ ОТ ДОРОЖНЫХ КАРТ

Многие продуктовые команды с радостью бы отказались от ежеквартальных дорожных карт продуктов, но их организации старомодны и привыкли к этим безнадежно устаревшим рабочим инструментам. И новаторские команды не знают, как переломить ситуацию и заставить компанию идти вперед.

В этом случае я предлагаю сделать следующее. Запланируйте продолжать использование действующего процесса с дорожными картами еще год или полгода, но с этого дня каждый раз, при ссылке на тот или иной пункт дорожной карты продукта или в обсуждении ее на презентации или собрании, напоминайте людям о фактическом бизнес-результате, получению которого призвано способствовать данное усовершенствование.

Если, скажем, вы работаете над включением в продукт PayPal как метода платежа (ради улучшения показателя конверсии), непременно укажите текущий коэффициент конверсии и результат, которого надеетесь достичь в конце. И главное, после того как новый набор функций будет полностью готов к использованию, обязательно подчеркните, как это сказалось на коэффициенте конверсии. Если результат хороший, отпразднуйте достижение. Если влияние не столь значительное, как вы надеялись, обратите внимание всех на то, что, хоть обновление и разработано, результат нельзя считать успешным. Укажите, какие полезные знания команда приобрела за прошедший период, но объясните, что у вас есть и другие идеи о том, как получить желаемый результат.

Со временем (на это может уйти около года) организация должна сместить фокус с запуска конкретных обновлений к определенной дате на достижение намеченных бизнес-результатов.

Но если вы хотите, чтобы этот подход сработал, помните о причинах того, почему заинтересованные стороны наших компаний так любят дорожные карты.

Они хотят ясно видеть, над чем вы работаете, и быть уверенными в том, что вы работаете над самыми важными задачами.

Они хотят иметь возможность планировать бизнес-деятельность, а для этого им нужно знать, когда будут происходить важнейшие события.

Современная альтернатива дорожным картам позволяет избавить этих людей от поводов для беспокойства по обоим пунктам. Команды работают над бизнес-целями, приоритетность которых определена лидерами. Мы честно и открыто рассказываем о достигнутых ключевых результатах и в случаях, когда действительно важно выдержать сроки поставки продукта на рынок, берем на себя повышенные обязательства.

МАСШТАБИРОВАНИЕ: ПРОЦЕСС

ОБЗОР

То, что компании, становясь больше и сложнее, менее охотно идут на риск, понятно и объяснимо. Пока компания мала, ей нечего терять, но, как только ее масштаб растет, на карту поставлено уже многое, и сотрудники разных функциональных подразделений изо всех сил стараются защитить эти активы.

Часто компании, чтобы защитить достигнутое, внедряют формализацию и стандартизацию всего, что в ней делается, надеясь таким образом сократить количество ошибок и снизить риск. Этот процесс охватывает все аспекты бизнес-деятельности — от возмещения командировочных расходов и запросов на изменения в отчетах до того, как мы исследуем и поставляем продукт на рынок. Хотя в таких областях, как отчетность расходов, это раздражает, вряд ли это сколько-нибудь заметно скажется на успехе компании.

В компании очень легко внедряются процессы, определяющие ее подход к разработке тех продуктов, которые могут стать настоящей палкой в колесе инноваций. Конечно, никто не ставит эти палки намеренно, но меня не перестает удивлять, как же часто это случается. Например, agile-методы весьма эффективно способствуют последовательным инновациям. Тем не менее несколько компаний, консультирующих по вопросам процесса и специализирующихся на внедрении Agile на этапе масштабирования, предлагают методы и структуры, якобы призванные обеспечить успешный переход компании к увеличению количества инженеров-программистов, но на деле лишающие даже малейшей надежды на инновации.

Впрочем, так бывает не всегда. Многие лучшие в мире компании по выпуску высокотехнологичных продуктов — очень крупные и весьма успешно масштабировали свои продуктовые и инженерно-технологические подразделения. И все методы и методики, описанные в этой книге, предназначены для того, чтобы помочь вам сохранить способность к последовательным инновациям в то время, когда ваша компания продолжает расти и становится все сложнее.

ГЛАВА 61

РАБОТА С КЛЮЧЕВЫМИ ЛИЦАМИ

Подозреваю, что многие менеджеры продукта считают управление ключевыми лицами, или заинтересованными сторонами16, нелюбимой частью работы. И я не намерен утверждать, что она простая, однако можно существенно облегчить этот вид деятельности и сделать его более приятным.

Для начала рассмотрим, кто такие заинтересованные стороны и каковы обязанности продакт-менеджера в построении взаимоотношений с ними. Мы также поговорим о том, каким образом вы можете добиться успеха на этом поприще.

КТО ТАКИЕ ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ

Во многих компаниях по выпуску технологичных продуктов практически все сотрудники считают, что им есть что сказать на этот счет. Им, конечно же, небезразлично, над чем они работают, и у них есть множество идей, основанных либо на собственном опыте использования продуктов, либо на мнении потребителей. Но независимо от того, что думают эти люди, большинство из них нельзя отнести к категории заинтересованных сторон. Они часть большого сообщества — и один из источников вводных данных о продукте наряду со многими, многими другими.

Один в высшей мере практичный тест позволяет быстро определить, стоит ли считать человека заинтересованной стороной. Для этого понадобится ответить на вопрос, обладает ли этот человек правом вето и может ли он каким-либо образом помешать вам запустить в производство новый продукт или фичу.

К заинтересованным сторонам обычно относят:

высшее руководство компании — СЕО и глав отдела продаж и маркетинга, инженерно-технического подразделения;

деловых партнеров, которые гарантируют согласованность продукта и бизнеса;

финансистов, которые помогают убедиться, что продукт соответствует финансовым особенностям и модели компании;

юристов, которые проверят, что у вашего предложения есть перспективы с точки зрения правовой защиты;

специалистов в области соответствия нормативным требованиям, которые подтвердят, что ваша идея соответствует всем установленным в отрасли стандартам или политикам;

специалистов в области развития бизнеса, которые убедят вас в том, что ваше предложение не нарушает условий текущих контрактов и договоренностей.

Бывают и другие заинтересованные стороны, но общую идею вы, думаю, поняли.

В стартапе мало заинтересованных сторон, потому что компания еще очень мала, и, честно говоря, ей почти нечего терять. Но в крупных организациях многие люди решительно и упорно защищают ее весьма весомые активы.

ОБЯЗАННОСТИ МЕНЕДЖЕРА ПРОДУКТА

Во взаимоотношениях с заинтересованными сторонами менеджер продукта несет ответственность за полное понимание всех факторов и ограничений, важных с точки зрения разных представителей этой группы, и донесение этих знаний до своей продуктовой команды. Никто не пожелает работать над продуктом, имеющим все шансы понравиться потребителю, а потом на обзорном совещании узнать, что некоторые условия делают невозможным дальнейшее развертывание его детища. А подобное случается гораздо чаще, чем вы, возможно, думаете, и каждый раз при этом компания еще на йоту теряет веру в свою продуктовую команду.

Если продакт-менеджер стремится к широте знаний, которая позволит его компании вырабатывать эффективные решения для любых проблем, то, помимо необходимости знать о преградах и поводах для беспокойства всех заинтересованных сторон, ему очень важно убедить каждую из них в том, что он не только понимает их проблемы, но и стремится предложить решения, выгодные и полезные как потребителю, так и заинтересованной стороне. И делать это нужно искреннее. Я подчеркиваю это, потому что без доверия к вам заинтересованная сторона либо усилит сопротивление, либо как минимум будет пытаться контролировать вас во всем.

СТРАТЕГИИ УСПЕХА

Успех во взаимоотношениях с заинтересованными сторонами означает, что они уважают вас и ваш вклад в достижения компании. Они верят, что вы понимаете их сомнения и трудности и предлагаете подходящие и выгодные им решения, что вы будете сообщать обо всех важных изменениях. И главное, они дают вам свободу действий для поиска наилучших решений, даже если в итоге эти решения будут сильно отличаться от первоначального плана.

Построить такие отношения с заинтересованными сторонами не так уж и сложно, но для этого необходимо быть компетентным менеджером по продукту, а именно: глубоко понимать своих потребителей, разбираться в аналитических данных, технологиях, отрасли, особенно в бизнесе. Без соблюдения этих условий вам не будут доверять — и, честно говоря, это правильно.

Как известно, лучший способ продемонстрировать свой профессионализм — это охотно и открыто делиться с другими всем, что знаешь сам. Взяв его за основу, вы придете к выводу, что лучше всего общаться с ключевыми заинтересованными сторонами лично, сесть с ними за один стол и внимательно выслушать все, что они скажут. Нужно объяснить им, что чем лучше вы понимаете их требования и ограничения, тем качественнее будут ваши решения. Задавайте им как можно больше вопросов. Будьте открыты и ничего не утаивайте.

В работе с заинтересованными сторонами менеджеры продукта часто допускают ошибку: они показывают им свое решение после того, как оно уже воплощено в жизнь. И тут возникают проблемы, потому что продакт-менеджер недостаточно хорошо понимал существующие преграды для его производства и вывода на рынок. Разочарование ждет не только заинтересованную сторону, но и технарей, которым придется переделывать работу. Поэтому возьмите за правило предварительно обсуждать свои идеи с ключевыми заинтересованными сторонами на этапе исследования продукта — до того, как включите в бэклог задачу по реализации. Это один из решающих факторов в успехе исследования продукта. На этом этапе вам следует убедиться, что предлагаемые решения действительно ценные, удобные в использовании (с привлечением к подтверждению потребителей) и выполнимые (с привлечением инженеров-программистов), а также что все заинтересованные стороны их поддержат.

В компаниях я часто наблюдают такую нехорошую ситуацию, когда все сводится к противостоянию мнений менеджера продукта и заинтересованной стороны. В этом случае обычно выигрывает последняя, так как стоит на более высокой ступени организационной иерархии. Однако, как я уже не раз говорил, менеджер может изменить ход игры, быстро проведя соответствующий тест для сбора подтверждений в пользу перспективности своей идеи. Перестаньте же обмениваться мнениями — обменивайтесь данными! Открыто делитесь всем, что вам удалось узнать. Кстати, вполне возможно, в итоге окажется, что неправы были оба. Исследование продукта — это самое время для таких тестов.

Прежде всего речь идет о налаживании личных взаимоотношений, основанных на взаимном уважении и сотрудничестве. В большинстве компаний, чтобы держать заинтересованные стороны в курсе событий и получать их отзывы о новых идеях, менеджеру продукта приходится тратить два-три часа в неделю, примерно полчаса на встречу с каждой из сторон. Я предпочитаю заниматься этим во время еженедельных обедов или кофе-брейков.

Многие менеджеры по продукту мне говорили, что для тестирования бизнес-жизнеспособности своих идей на всех основных заинтересованных сторонах планируют большое совещание. На этом мероприятии они рассказывают, чем собираются заниматься их продуктовые команды, обычно в форме презентации в PowerPoint. Должен сказать, такой подход может привести к двум весьма серьезным и потенциально крайне нежелательным с точки зрения карьерного роста проблемам. Во-первых, презентации — это самый плохой способ тестирования бизнес-жизнеспособности идей и продуктов. Такие мероприятия слишком неопределенны, а между тем юрист хочет увидеть реальные скрины, страницы и словесные формулировки; глава маркетингового подразделения — дизайн продукта; специалист по вопросам безопасности — то, что, по вашему замыслу, будет делать новый продукт. На все эти вопросы презентация отвечает из рук вон плохо. А вот пользовательские прототипы высокой детализации подходят для этой цели идеально. Я всегда призываю менеджеров по продукту крупных компаний доверять подтверждающим подписям и одобрениям, только если они получены после демонстрации прототипа. Слишком уж часто мне приходилось наблюдать, как руководители, согласившись на что-либо после презентации, были глубоко разочарованы при виде реального продукта, а иногда и откровенно злились.

Кроме того, групповую среду нельзя считать подходящим форумом для создания сильных высокотехнологичных продуктов. Так называемая разработка комитетом, если повезет, дает посредственный результат. Лучше встретиться с каждой заинтересованной стороной с глазу на глаз, показать прототип высокой детализации и выслушать все их тревоги и опасения.

Возможно, вам кажется, что для этого придется проделать много дополнительной работы, но, уж поверьте мне, в конечном счете вы существенно сократите свою рабочую нагрузку, сэкономите массу времени и убережете себя от многих бед.

И последнее, некоторые заинтересованные стороны могут не понимать, чем занимается подразделение по разработке продуктов, иногда они даже чувствуют исходящую от него угрозу. Отнеситесь к этому серьезно. Возможно, вам придется объяснить им, как работают компании по выпуску высокотехнологичных продуктов и почему дело в них обстоит именно так.

Деградация

О серьезных трудностях управления организацией на этапе роста, особенно о важности упорной работы по поддержанию высокого качества труда сотрудников по мере масштабирования, написано много. Никто не спорит с тем, что с увеличением размера и сложности способность большинства компаний быстро и последовательно внедрять инновации ухудшается. Многие специалисты связывают это с проблемами качества персонала, процесса и коммуникаций на этапе масштабирования бизнеса, а некоторые считают неизбежностью. Я же вижу во многих компаниях следующий антипаттерн: поначалу они весьма преуспевают и агрессивно и уверенно растут, но потом, спустя некоторое время, совершенно непреднамеренно меняют хорошее поведение на плохое.

По моим сведениям, об антипаттерне раньше никто не писал, и, подозреваю, мои следующие слова вызовут у многих сильный дискомфорт. Однако это действительно очень серьезная проблема, к которой, по-моему, необходимо привлечь ваше внимание, поскольку если о ней знать, то предотвратить ее несложно.

Обычно события развиваются следующим образом: предположим, вы стартап на поздней стадии развития или компания на стадии роста. Вы уже достигли соответствия «продукт — рынок», по крайней мере для первоначального продукта. И раз вам это удалось, по всей вероятности, многие важные вещи вы сделали правильно. Но потом вы получаете неплохое финансирование или кто-то из членов совета директоров вашей компании настоятельно рекомендует вам привлечь «кого-нибудь из взрослых для присмотра» — опытных и знающих людей из компании с известным брендовым именем.

В том-то все дело! Эти новые нанятые люди часто бывают выходцами из крупных брендовых компаний, которые уже перестали расти, давным-давно потеряли способность к инновациям и много лет держатся на плаву только за счет репутации бренда. Все эти причины заставляют компанию сойти с пути к успеху, на который она когда-то встала, — потому-то люди из нее и уходят.

Разве вы не предпочли бы нанимать сотрудников и руководителей исключительно из Google, Facebook, Amazon и Netflix? Конечно же да! Но эти люди в огромном дефиците, а вот в других компаниях сильных и вполне доступных профессионалов хватает.

Допустим, вы молодая компания на этапе роста и решили нанять топ-менеджера — главу продуктового, технического или маркетингового подразделения — из известной брендовой компании, скажем из Oracle. Вашему совету директоров эта идея, скорее всего, по душе. Только вот если вы не сделали этого с самого начала, то новый лидер может предположить, что вы нанимаете его потому, что он отлично знает процесс — как определять нужный продукт и поставлять его на рынок. И он приносит с собой свою философию и взгляды на то, как все должно быть. И что еще хуже, нанимает людей, которые хотят и готовы работать именно так.

Обратите внимание: для примера я назвал Oracle, но эта компания, конечно же, в этом смысле не единственная. Из Oracle можно нанять отличных профессионалов: они очень любят скупать другие компании, часто очень хорошие. Однако тем сильным продакт-менеджерам, дизайнерам и инженерам-программистам, которых приобретают вместе с их фирмами, редко нравится корпоративная культура Oracle и ее подходы к созданию продукта.

Мне доводилось наблюдать антипаттерн на всех уровнях компании — от обычных технарей до СЕО. Да, это происходило не в одночасье, а длилось годами. Но я сталкивался с подобной ситуацией предостаточно раз, поэтому убедился: это действительно антипаттерн. Надо сказать, многие люди интуитивно чувствуют здесь проблему, но обычно видят в ней «синдром человека из большой компании». Однако скверно не столько то, что человек пришел из большой компании, сколько то, что там, откуда он пришел, люди не слишком сильны в деле разработки новых продуктов.

К счастью, я знаю два способа, которые позволят вам защититься от этой «заразы». Первый заключается в целенаправленном создании влиятельной продуктовой культуры, которая должна быть настолько устоявшейся и заметной, чтобы каждый новый сотрудник с порога понимал, что пришел в организацию совсем иного типа, которая гордится своим подходом к работе и использует только самые лучшие и передовые методы и практики. Люди, приходящие в Netflix, Airbnb или Facebook, понимают это с первых дней, и эти компании развивают свою культуру упорно и целенаправленно.

Второй способ — максимально четко донести нужную мысль во время собеседования и процесса адаптации новых сотрудников. В рамках своей консультативной деятельности я часто провожу для команд собеседования с кандидатами на руководящие должности, и, если человек пришел из компании с деградировавшей культурой, я бываю с ним предельно откровенен. Мы говорим о причинах того, почему его бывшая компания много лет не выпускала успешных новых продуктов; и я непременно обращаю его внимание на то, что новая компания очень заинтересована в его уме и способностях, но он, конечно же, ни в коем случае не должен приносить с собой неэффективные рабочие методы с предыдущего места работы.

По моему опыту, если говорить об этом открыто и честно, люди воспринимают все с пониманием. В сущности, во время нашей беседы они часто признаются, что именно из-за этого оттуда и ушли. Просто им нужно осознать это очень глубоко.

ГЛАВА 62

РАСПРОСТРАНЕНИЕ НОВЫХ ЗНАНИЙ О ПРОДУКТЕ

В стартапе обмен любыми новыми знаниями и полезной информацией происходит просто и естественно, ведь продуктовая команда и компания — это одно и то же. Однако по мере увеличения масштабов организации делать это становится сложнее, несмотря на то что важность таких коммуникаций повышается.

Одна из моих любимых методик весьма эффективно справляется с этой непростой задачей. Каждую неделю или две директор по продукту на общем собрании коллектива или аналогичном мероприятии уделяет от пятнадцати минут до получаса рассказу о том, что нового удалось узнать разным продуктовым командам в ходе исследования продукта за прошедший период. Обратите внимание, что говорить нужно о важных и действительно ценных уроках, а не о мелочах: что сработало, а что не сработало, какие подходы команды планируют попробовать на следующей неделе.

Обновление знаний всегда должно быть быстрым и качественным, поэтому-то я и предлагаю отдать бразды правления в руки топ-менеджера. Речь идет не о том, чтобы каждый менеджер продукта брал слово и подробно — гораздо подробнее, чем нужно большинству присутствующих на собрании, — в течение часа, а то и двух, рассказывал обо всем, что его команда узнала за неделю. Мероприятие ни в коем случае не должно превращаться в повтор анализа спринтов.

Обмен новейшей полезной информацией призван решить сразу несколько задач, как тактических, так и культурных.

Ценные знания важно доносить до максимально широкого круга людей, особенно если дела в компании идут не так, как хотелось бы. В придачу кто-нибудь из аудитории иногда высказывает идею или делится сведениями, которые помогают объяснить невпечатляющие результаты.

С помощью этого простого и полезного способа разные продуктовые команды компании узнают, чему научились другие, а также доводят эти полезные уроки до ведома руководства.

Метод стимулирует продуктовые команды сохранять фокус на больших и важных уроках, а не на экспериментах, которые не оказывают заметного влияния ни на потребителя, ни на компанию.

В культурном плане важно, чтобы компания понимала, что цель и суть исследования продукта и инноваций — это непрерывное проведение быстрых экспериментов и приобретение новых знаний на основе полученных результатов.

С точки зрения культуры также важно, чтобы разработчики продукта максимально честно и щедро делились новыми знаниями, рассказывая остальным, как они работают. Это помогает другим подразделениям понять, что продуктовые команды существуют не для «обслуживания бизнеса», а для решения проблем потребителей таким способом, чтобы это приносило пользу бизнесу.

ГЛАВА 63

ЗНАКОМЬТЕСЬ: КАМИЛЛА ХЕРСТ ИЗ APPLE

Я невероятно рад познакомить вас с еще одним очень эффективным менеджером по продукту, Камиллой Херст.

Камилла была менеджером по продукту в команде Apple, работавшей над iTunes. Как вы можете себе представить, учитывая революционность этого продукта, она многое пережила и многому научилась за годы, проведенные в компании, в период своего становления как профессионала в деле разработки новых продуктов. Особенно если принять во внимание, что в годы работы Камиллы в Apple осуществлялся переход iTunes с первоначальной системы предложения музыки на основе DRM (Digital Rights Management — управление правами на электронные продукты) на музыку, не защищенную такими правами, что, как покажет будущее, сыграло решающую роль в превращении рынка iTunes в массовый рынок.

Переход от ранних последователей к массовому рынку требовал серьезных усилий в разных направлениях: в продуктовой сфере, маркетинговой и их комбинации. Наглядным примером такой комбинации можно считать отношения, которые команда iTunes наладила с популярной телевизионной программой American Idol17.

Для команды iTunes этот период в ее истории стал одним из самых важных и заметных — и очень-очень непростым.

В 2008 году телевизионное шоу American Idol считалось легендой, даже иконой стиля; передачу дважды в неделю смотрели более 25 миллионов человек — непревзойденный показатель уровня повторного обращения.

Apple увидела в этом благоприятную возможность для открытия идеального целевого рынка в целях развития мощи iTunes и цифровой музыки. Было решено попробовать не просто продавать музыку конкурсантов, принимавших участие в шоу, но и сделать iTunes неотъемлемой частью жизни потребителей. Однако хотя потенциал и правда был поистине грандиозным, такими же оказались и трудности, с которыми столкнулась компания.

Вице-президент iTunes Эдди Кью и другие руководители заключили сделку; Камилла была менеджером по продукту многих программ интеграции и помогала выяснить, как осуществить замысел.

Приведу только один пример. Как известно, важнейший элемент шоу American Idol — это голосование, и Apple быстро поняла, что продажа музыки конкурсантов, скорее всего, будет сильно зависеть от его результатов. Так что, хоть приложение iTunes создавалось для того, чтобы представлять миру трендовую музыку и привлекать внимание к популярным названиям и именам, теперь нужно было действовать осторожно, чтобы не влиять на результаты голосования. Безусловно, это было чрезвычайно важно для продюсеров American Idol, ведь любые действия могли снизить и даже уничтожить те предвкушение и напряжение, с какими люди желали узнать, кто из участников продолжит борьбу на следующей неделе.

Кроме того, интеграция усилий разработчиков и маркетологов позволила команде сосредоточиться на в высшей степени четком портрете потребителя и целенаправленно работать над привлечением внимания именно этой группы, для чего решено было облегчить доступ к iTunes тем, кто еще не установил приложение.

Размышляя над решением этих и многих других сложнейших задач, Камилла и ее команда придумали технологические решения, удачно дополнявшие опыт просмотра шоу American Idol и при этом сделали iTunes ключевым элементом жизни фанатов этой шоу-программы. В итоге возникло новое направление бизнеса, которое в 2014 году, еще до перехода на потоковую передачу, оценивалось примерно в 20 миллиардов долларов!

Для меня это отличный пример того, как поистине великие менеджеры продукта находят креативные решения очень сложных проблем.

Впоследствии Камилла присоединилась к команде YouTube, а затем возглавила лондонское подразделение компании — разработчика приложения для такси Hailo. А сегодня она СЕО одного нью-йоркского стартапа.

ЧАСТЬ V

КУЛЬТУРА

Итак, мы с вами обсудили много важных тем, а теперь пора сделать отступление и подробнее рассмотреть диапазон и содержание функций менеджера продукта; узнать, как эти люди работают в составе продуктовых команд и какими методами пользуются для быстрого определения того, какие продукты стоит создать и предложить потребителю.

В работе продакт-менеджера довольно легко зациклиться на деталях, но ведь важнейшее условие успеха — сформировать хорошую продуктовую культуру.

В последних главах книги я расскажу о том, что важнее всего для вашего успеха. В частности, опишу, как ведет себя отличная продуктовая команда и как сильные продуктовые компании обеспечивают свои команды средой для процветания.

ГЛАВА 64

ХОРОШАЯ ИЛИ ПЛОХАЯ ПРОДУКТОВАЯ КОМАНДА

Как уже говорилось, мне в жизни повезло: я имел счастье работать с лучшими в мире командами по выпуску технологичных продуктов; с людьми, создающими продукты, которые вы используете каждый день и очень-очень любите; с командами, которые в буквальном смысле слова меняют наш мир. Но меня привлекали и для помощи компаниям, чьи дела шли не так хорошо: стартапам, которые изо всех сил пытались привлечь к себе хоть немного внимания рынка, прежде чем у них закончатся деньги; крупным компаниям, безуспешно старавшимся возродить прежний успех на ниве инноваций; командам, которые оказались не способны непрерывно повышать ценность своего бизнеса; лидерам, глубоко разочарованным тем, что на воплощение в жизнь идей требуется много времени; инженерам, недовольным своими продакт-менеджерами. В результате такого опыта я узнал, что лучшие продуктовые компании создают высокотехнологичные продукты и делают все совсем не так, как остальные. Между прочим, я имею в виду не какие-то незначительные отличия, а разницу во всем, от поведения руководителей, уровня полномочий команд до подхода к финансированию, подбору персонала, выпуску продуктов и сотрудничеству при поиске эффективных решений проблем своих потребителей.

С благодарностью отсылая вас к классическому посту Бена Горовица Good Product Manager/Bad Product Manager («Хороший/плохой менеджер продукта»), я обращаюсь сейчас к тем, кто не имел возможности работать в сильной продуктовой команде или наблюдать за ее работой. В этой главе я постараюсь дать вам общее представление о некоторых значимых различиях между сильными и слабыми продуктовыми командами.

У хороших команд есть захватывающее видение продукта, которое они реализуют с миссионерской страстью. Плохие команды — это команды «наемников».

Хорошие команды черпают вдохновение и идеи из своего видения продукта и целей; внимательного наблюдения за проблемами и трудностями потребителя; анализа данных, генерируемых пользователями при употреблении продукта; постоянного стремления применять новые технологии для решения реальных проблем. Плохие команды просто получают указания от своего отдела продаж и потребителей.

Хорошие команды понимают, кто основные заинтересованные стороны в их продукте; им известны ограничения, в условиях которых работают эти люди, и нацелены на поиск решений, не только полезных для пользователей и клиентов, но и эффективно работающих в рамках бизнес-ограничений. Плохие команды просто принимают требования заинтересованных сторон.

Хорошие команды мастерски владеют различными методиками быстрого тестирования идей и определяют, какие из них стоит воплотить в жизнь. Плохие команды проводят собрания, составляя на них дорожные карты.

Хорошие команды любят проводить «мозговые штурмы» с участием авторитетных экспертов из разных подразделений компании. Плохие команды обижаются, когда «чужаки» лезут не в свое дело.

В хороших командах продакт-менеджер, дизайнер и инженер-программист трудятся плечом к плечу, в полной мере осознавая необходимость компромисса между функциональностью, пользовательским опытом и технологией реализации. В плохих командах люди сидят в своих «отсеках» и требуют, чтобы другие делали запросы на их услуги в соответствующей форме с четким соблюдением графика.

Хорошие команды постоянно тестируют новые идеи, чтобы не перестать быть новаторами, но делают это так, чтобы доход и бренд компании были защищены. Плохие команды ждут сверху разрешения на каждый тест.

Хорошие команды настаивают на том, что у них должны быть все специалисты, необходимые для создания хитов, например сильный дизайнер продукта. В плохой команде о таких специалистах даже не слышали.

В хороших командах инженеры-программисты ежедневно тестируют прототипы на этапе исследования и благодаря этому находят новые способы улучшения продукта. Плохие команды дают на оценку прототипы технарям только на этапе планирования спринта.

Хорошие команды каждую неделю взаимодействуют с конечными пользователями и клиентами, чтобы лучше понимать их запросы и проблемы и видеть их реакцию на самые новые идеи. Плохие команды думают, что они и есть потребители.

Хорошие команды знают, что многие из их любимых идей не понравятся потребителям, а даже если люди их примут, понадобится нескольких итераций, чтобы достичь желаемого конечного результата. Плохие команды просто создают продукт из дорожной карты, довольствуясь при этом тем, что соблюдают установленные сроки и обеспечивают нужное качество на отдельных этапах разработки.

Хорошие команды понимают необходимость скорости и знают, что быстрые итерации — это ключ к инновациям; по их мнению, эта скорость произрастает на почве использования правильных методик, а не принудительного труда. Плохие команды объясняют низкую скорость работы недостаточным усердием коллег.

Хорошие команды берут на себя обязательства с высокими требованиями только после того, как всесторонне оценят запрос и убедятся, что у них есть жизнеспособное решение, выгодное и полезное как для потребителя, так и для бизнеса. Плохие команды жалуются на то, что в их компании всем заправляет отдел продаж.

Хорошие команды применяют инструменты, позволяющие немедленно оценивать, как используется их продукт, и на основании этих данных оперативно вносить коррективы. Плохие команды считают, что иметь возможность просматривать аналитику и отчеты неплохо, но в этом нет особой необходимости.

Хорошие команды вводят новые функции в продукт и выпускают релизы постоянно, зная, что непрерывный поток небольших релизов обеспечивает клиентов более надежным решением. Плохие команды тестируют продукт вручную в самом конце болезненного этапа интеграции, а затем одним махом делают релиз.

Хорошие команды ставят во главу угла референcных клиентов. Плохие команды одержимы борьбой с конкурентами.

Хорошие команды празднуют то, что им удается значительно улучшить бизнес-результаты своей компании. Плохие команды празднуют то, что им удается выпустить хоть какой-нибудь продукт.

Если многое из характеристик плохих компаний имеет отношение к вам, я очень надеюсь, что вы как можно скорее поднимете планку для своей команды. Подумайте об использовании методик, описанных в книге, чтобы, так сказать, почувствовать разницу.

ГЛАВА 65

ПРИЧИНЫ ПРОБЛЕМ С ИННОВАЦИЯМИ

Я определяю последовательные инновации как способность команды постоянно повышать ценность своего бизнеса. В результате роста многие организации теряют способность к инновациям, что, конечно же, не может не расстраивать руководство и членов продуктовых команд. Чаще всего по этой причине люди уходят из крупных компаний в стартапы.

Тем не менее потерю способности крупных и устоявшихся компаний к инновациям не стоит считать неизбежным злом. Наиболее последовательные новаторы в нашей отрасли очень велики: взять хотя бы Amazon, Google, Facebook и Netflix.

На мой взгляд, компаниям, которые перестали заниматься инновациями вследствие увеличения масштаба, не хватает одной или нескольких из перечисленных ниже черт.

Культура, ориентированная на клиента. Как говорит СЕО Amazon Джефф Безос, «клиенты всегда замечательно, волшебно недовольны, даже когда утверждают, что совершенно счастливы, и дела идут великолепно. Сами того не осознавая, клиенты всегда хотят улучшений, и ваше желание порадовать их побуждает вас изобретать что-то новое». Компании, не сосредоточенные на потребителе и не поддерживающие с ним прямого и частого контакта, со временем теряют такой настрой, а вместе с ним лишаются и главного источника вдохновения.

Захватывающее видение продукта. К тому времени когда компании становятся крупными и сложными, большинство из них в основном уже реализуют первоначальное видение продукта, поэтому команде довольно трудно понять, каким будет следующее. Положение дел усугубляется еще и тем, что основатели, бывшие хранителями видения, к этому времени нередко уже покидают компанию. В таких случаях необходимо заполнить эту пустоту — обычно это может быть СЕО либо вице-президент по продукту.

Направленная стратегия развития продукта. Очевидно, что для того, чтобы потерпеть крах в деле развития продуктов, нужно постараться угодить всем. Однако крупные компании часто об этом забывают. Их стратегия должна включать логически продуманный перечень целевых рынков, на которые следует направить свои усилия продуктовым командам.

Отличные менеджеры продукта. Отсутствие сильного, квалифицированного продакта нередко становится преградой для инноваций. В маленькой компании эту роль играет СЕО или один из основателей, но в крупной и сложной организации успех каждой продуктовой команды в значительной степени зависит от сильного, компетентного менеджера продукта.

Стабильные продуктовые команды. Обязательное условие для последовательных инноваций — наличие продуктовой команды, у которой есть возможность досконально изучить среду, технологии и проблемы потребителя. А это невозможно, если члены команды постоянно меняются.

Участие инженеров-программистов в исследовании продукта. Залогом успешных инноваций в компании обычно считается наличие в команде квалифицированных технарей, но только при условии, что, во-первых, их включают в разработку продукта с самого начала, а не в конце; а во-вторых, им известны проблемы клиента.

Корпоративная смелость. Не секрет, что по мере роста многие компании, неохотно идут на риск. Понятное дело, ведь им теперь есть что терять. Но лучшие компании по производству технологических продуктов знают, что полностью прекратить рисковать — это самый опасный выбор. Нам нужно подходить к делу с умом, но для последовательных инноваций невероятно важна готовность идти на риск и менять статус-кво бизнеса.

Продуктовые команды с широкими полномочиями. Даже если компания начинала с использования передовых рабочих методик, по мере роста она может деградировать в этом плане. Так что если вы раздаете командам дорожные карты продукта, можете больше не рассчитывать на огромные преимущества, обеспечиваемые самоуправляемыми и самостоятельными продуктовыми командами. Расширение полномочий означает, что команды имеют право решать порученные им бизнес-задачи наилучшим, с их точки зрения, способом.

Продуктовый образ мышления. В компании с установками на ИТ продуктовые команды существуют для обслуживания потребностей бизнеса, а в компаниях, где во главе угла стоит продукт, их предназначение — обслуживать клиентов компании так, чтобы обеспечивались и потребности бизнеса. Различие между этими двумя установками приводит к разным результатам.

Время для инноваций. По мере того как компания разрастается, продуктовые команды начинают уделять внимание только тем видам деятельности, которые, как мы это называем, позволяют бизнесу оставаться на плаву. Они исправляют ошибки, реализуют возможности для разных подразделений компании, занимаются техническими долгами и так далее и тому подобное. Если это относится к вам, не удивляйтесь отсутствию инноваций. Все это нормальные и даже полезные дела, если они не первостепенны; у ваших команд должно оставаться время на решение более важных задач.

Надеюсь, вы заметили, что приведенный выше список, в сущности, описывает культуру последовательных инноваций. Иными словами, дело прежде всего в культуре, а не в процессе или чем-нибудь другом.

ГЛАВА 66

ПРИЧИНЫ ПРОБЛЕМ С ТЕМПАМИ РАЗРАБОТКИ

Как правило, по мере увеличения масштабов и сложности организаций в них замедляется все. Впрочем, необязательно так должно случиться. В лучших компаниях, напротив, с ростом может наблюдаться ускорение темпов работы. Если это не ваш случай, то в первую очередь вам нужно обратить внимание на следующие просчеты:

Работа с техническим долгом. Архитектура часто не способствует быстрой эволюции продукта и не облегчает эту задачу разработчикам. Безусловно, ее не исправишь в одночасье, так как здесь требуются постоянные и согласованные усилия.

Отсутствие сильных менеджеров продукта. Отсутствие компетентного менеджера продукта обычно главная причина его медленной эволюции. Недостатки этого специалиста влияют на команду по-разному, но особенно наглядно то, что ее члены работают как «наемники», а не «миссионеры». Продакт-менеджер не вдохновляет людей и не уделяет внимания евангелизации продукта, над которым они трудятся, и команда просто перестает ему верить.

Отсутствие операционного менеджера с техническими навыками. Важнейшая задача этого специалиста заключается в устранении препятствий, а их список по мере роста технологической компании растет в геометрической прогрессии. И большинство не исчезают сами собой, если их устранением продуманно и целенаправленно не занимается менеджер проекта.

Редкие циклы релизов. Большинство команд, чья работа продвигается низкими темпами, слишком редко выпускают готовые версии продукта. Ваша команда должна делать релизы не реже раза в две недели (превосходные команды делают это несколько раз в день). Как правило, чтобы исправить ситуацию, нужно серьезнее относиться к автоматизации тестирования и релизов, чтобы команда могла работать быстрее и увереннее.

Отсутствие видения и стратегии развития продукта. Команда обязана ясно видеть общую картину и знать, какой вклад она делает в общее дело.

Отсутствие стабильных продуктовых команд, работающих в одном месте. Если команды удалены территориально или, хуже того, технарей привлекают через аутсорсинг, такое положение вещей крайне негативно сказывается не только на инновациях, но и на темпах деятельности компании. Затрудняется даже общение сотрудников. И со временем все становится настолько плохо, что многие аутсорсинговые фирмы добавляют дополнительный слой персонала для координации и коммуникаций, что обычно только усугубляет ситуацию.

Слишком позднее включение инженеров-программистов в исследование продукта. Инженеры должны участвовать в исследовании продукта с самого начала выработки идеи. Если вы привлечете их, чтобы продакт-менеджер и дизайнер имели возможность учесть их мнение, инженеры смогут предложить альтернативные подходы, с технической точки зрения реализуемые значительно быстрее. В противном случае их несравнимо важный вклад будет сделан слишком поздно.

Слишком позднее включение дизайнеров по продукту в исследование, в результате чего им приходится делать свою работу одновременно с разработчиками, которые уже пытаются создать продукт, не только замедляет разработку, но и становится причиной скверного дизайна.

Изменение приоритетов. Надо учитывать, что быстрая смена приоритетов ведет к значительной текучести персонала и снижает как моральный дух, так и производительность коллектива.

Культура, основанная на консенсусе. Многие компании стремятся к консенсусу, и хоть они обычно делают это с благими намерениями, на практике это означает, что принимать решения становится очень трудно и дела начинают идти со скоростью улитки.

Конечно, можно назвать еще множество причин медленной работы над продуктом, но, по моему опыту, здесь перечислены главные виновники.

ГЛАВА 67

СОЗДАНИЕ СИЛЬНОЙ ПРОДУКТОВОЙ КУЛЬТУРЫ

В этой книге мы говорили о продуктовых командах и методиках исследования успешных продуктов, но, надеюсь, вы заметили, что на самом деле речь в ней шла о продуктовой культуре, — культуре, в которой во главу угла ставится продукт. Я рассказал, как мыслят великие компании, выпускающие программные продукты, как они организуют свою деятельность, как работают.

К осмыслению продуктовой культуры я подхожу с двух сторон. Во-первых, может ли компания непрерывно заниматься инновациями, постоянно разрабатывая ценные решения для потребителей. Это мы делаем на этапе исследования продукта. А во-вторых, как она его исполняет? Какой бы великой и перспективной ни была идея, она ничего не стоит, если вы не можете создать и предложить потребителям готовый продукт. В этом суть этапа реализации продукта.

В последней главе я опишу, чем отличается сильная инновационная культура от сильной культурой исполнения.

Итак, что означает иметь сильную инновационную культуру? Инновационная культура — это культура:

экспериментаторства: команды знают, что могут проводить тесты и одни будут успешными, другие нет, но это приемлемо и понятно;

открытости и непредубежденности: команды знают, что хорошие идеи приходят откуда угодно и не всегда очевидны сразу же;

широких полномочий: отдельным сотрудникам и командам предоставлена большая свобода действий при проверке самых разных и смелых идей;

технологий: источником вдохновения для истинных инноваций могут служить не только потребители продукта, но и новые технологии и аналитические данные;

команд, досконально знающих свой бизнес и потребителей: все команды, в том числе продуктовые, глубоко понимают потребности и ограничения своего бизнеса, как и своих пользователей и клиентов (и имеют к ним доступ);

разнообразия навыков и персонала: команды понимают, какой большой вклад в выработку инновационных решений вносит разнообразие навыков и опыта, особенно в области технологий, дизайна и продукта как такового;

применения методик для исследования продукта: предполагает наличие механизмов для быстрого и безопасного тестирования идей, которые гарантируют защиту бренда, доходов компании и интересов потребителей и сотрудников.

А что же означает сильная культура исполнения? Это культура:

срочности: люди чувствуют себя так, словно они солдаты на войне; если не работать быстро и оперативно, может произойти что-то скверное;

обязательств с высокими требованиями: команды осознают потребность в обязательствах (и их силу), но стремятся брать на себя только обязательства с высокими требованиями (мы говорили о них выше);

широких полномочий: в распоряжении команд имеются инструменты, ресурсы и разрешение делать все необходимое для выполнения взятых обязательств;

ответственности: отдельные сотрудники и команды чувствуют себя в полной мере ответственными за взятые на себя обязательства, что подразумевает и негативные последствия за их невыполнение, которые необязательно выражаются в увольнении — подобное случается только в экстремальных ситуациях или в случае неоднократного невыполнения обязательств. Последствия чаще всего выливаются в потерю репутации среди коллег;

сотрудничества: самоорганизация и свобода действий безусловно важны, но для достижения больших и значимых целей гораздо важнее уметь работать сообща;

результатов: необходимо фокусироваться на результате, а не на процессе;

признания: команды часто ищут для себя подсказки в том, что вознаграждается в компании и что в ней приемлемо. Какую команду ждет вознаграждение — ту, что предлагает перспективную новую идею, или ту, что получила реальный результат, взяв на себя повышенные обязательства? И какое сообщение получают люди при виде того, как легко прощается невыполнение обязательств?

Итак, перечисленные характеристики позволяют нам определить обе культуры, но в связи с этим напрашиваются непростые вопросы:

Следует ли считать, что инновационная культура по своей природе тем или иным образом конфликтует с культурой исполнения?

Означает ли наличие сильной культуры исполнения в компании стрессовую рабочую среду (или хуже того)?

Какого типа людей, включая лидеров, привлекает культура каждого типа и какие люди должны в них работать?

Могу с уверенностью сказать, что некоторые компании сильны как в инновациях, так и в исполнении. Самый яркий пример — Amazon. Однако всем отлично известно, что рабочая среда в ней не для слабонервных. Я обнаружил, что в большинстве компаний, исключительно сильных в исполнении, довольно тяжело работать.

Судя по моему опыту, компаний, сильных по обоим параметрам, не так уж много. Одни хороши в исполнении, но слабы в инновациях; другие сильны в инновациях и неплохи в исполнении. И, к сожалению, удручающе много компаний оставляют желать лучшего и в том и в другом. В первую очередь это касается старых компаний, продукты которых давным-давно утратили шарм, но у них все еще есть сильный бренд и огромная клиентская база, на которую они могут опереться.

В любом случае я очень надеюсь, что вы и ваша команда попробуете оценить себя по параметрам инноваций и исполнения, а затем спросите, что вам хотелось бы изменить (если вы уверены в необходимости этого) как команде и компании в целом.

БЛАГОДАРНОСТИ

В этой книге я хотел объединить передовой опыт лучших компаний по выпуску программного обеспечения, поэтому ее характер предполагает, что моими учителями были многие исключительные люди. Мне невероятно повезло поработать с лучшими умами и компаниями из нашей сферы деятельности. Каждый из них научил меня чему-то ценному и полезному, но некоторые оказали на меня настолько глубокое и неизгладимое влияние, что я обязан их здесь поблагодарить.

Прежде всего это мои партнеры по Silicon Valley Product Group. Теперь они и мои коллеги, потому что меня потряс их профессионализм и знания. Я многому научился у каждого из этих людей. Я говорю о Лие Хикман, Мартине Лаученгко и Крисе Джонсе.

Я также должен поблагодарить Питера Экономи, Джеффа Паттона и Ричарда Нарраморе за помощь в рецензировании и улучшении книги. Основой для нее послужил материал, наработанный в Netscape Communications. Именно Netscape дала мне беспрецедентную возможность учиться: в ней я многое узнал о продукте и о лидерстве, работая бок о бок с такими блестящими людьми, как Марк Андриссен, Барри Аппельман, Дженнифер Бэйли, Джим Барксдейл, Питер Карри, Эрик Хан, Бэзил Хэшем, Майк Гомер, Бен Горовиц, Омид Кордестани, Кенг Лим, Боб Лисбон, Дебби Мередит, Майк Мак-Кью, Дэнни Шейдер, Шармила Шахани, Рам Шрирам, Билл Терпин и Дэвид Вейден.

Из eBay я обязан особо отметить Марти Эбботта, Майка Фишера, Чака Гейгера, Джеффа Джордана, Джоша Копельмана, Шри Махеша, Пьера Омидьяра, Линн Риди, Стефани Тилениус и Мейнарда Уэбба. Все они оказали на меня огромное влияние и внесли неоценимый вклад в изложение тем, затронутых в этой книге, либо посредством прямой помощи и коучинга, либо благодаря их руководству и тому, что мне посчастливилось собственными глазами наблюдать за их работой.

Время, проведенное в упомянутых потрясающих компаниях, стало для меня бесценным опытом обучения, а, начав сотрудничать с командами разработчиков в рамках консультативно-коучинговой деятельности в структуре SVPG, я обнаружил, что огромную пользу мне также принесла возможность познакомиться и поработать с лидерами продукта из многих лучших компаний в нашей отрасли. Этих людей слишком много, чтобы перечислить здесь всех, но они, конечно, знают, о ком я говорю, и я выражаю огромную благодарность каждому из них.

В основу этой книги легли материалы, написанные для моего блога и новостной рассылки. Я публиковал их на протяжении ряда лет, и каждая из обсуждаемых здесь тем представлена намного полнее и глубже благодаря отзывам и комментариям тысяч продакт-менеджеров и лидеров продукта из самых разных уголков мира. Спасибо всем, кто прочитал и прокомментировал мои статьи и поделился ими.

И наконец, те, кто хорошо знаком с культурой компаний, в которых я работал, отлично понимают, как много времени я там провел и что я вряд ли осуществил бы все свои замыслы без поддержки моей жены и замечательных детей.

ОБ АВТОРЕ

Прежде чем основать Silicon Valley Product Group и продолжить заниматься главным делом своей жизни — помогать людям создавать успешные продукты путем написания книг, выступлений, консультаций и коучинга, Марти Каган был топ-менеджером и отвечал за выявление и создание новых продуктов в ряде успешнейших компаний, в том числе в Hewlett-Packard, Netscape Communications и eBay.

В начале карьеры Марти десять лет проработал инженером-программистом в Hewlett-Packard Laboratories; он исследовал технологии разработки программного обеспечения и создал несколько программных продуктов для других разработчиков. После Марти присоединился к еще совсем юной Netscape Communications, где приложил руку к рождению интернет-индустрии. Он работал на соучредителя Netscape Марка Андриссена; был вице-президентом по платформе и инструментам корпорации, а затем по приложениям для электронной торговли; помогал эффективно использовать новейшие технологии как совсем молодым интернет-стартапам, так и богатейшим компаниям из списка Fortune 500.

До недавнего времени Марти был старшим вице-президентом по продукту и дизайну в eBay, где отвечал за исследование продуктов и сервисов для глобального сайта электронной торговли компании.

За свою карьеру Марти сыграл большинство ролей, имеющихся в современной компании по выпуску программного обеспечения (либо руководил такими людьми), включая программирование, менеджмент и маркетинг продукта, UX-дизайн, тестирование софта, управление инженерно-техническим подразделением и общий менеджмент.

В рамках деятельности в SVPG Марти как приглашенный докладчик часто выступает на крупных конференциях и в ведущих компаниях по всему миру.

Он выпускник Калифорнийского университета в городе Санта-Круз; имеет степень бакалавра в области компьютерных наук и прикладной экономики (1981 год) и диплом Института топ-менеджмента Стэнфордского университета (1994 год).

УЗНАЙТЕ БОЛЬШЕ

Сайт Silicon Valley Product Group (www.svpg.com) разрабатывался как бесплатный ресурс с открытым доступом; на нем мы делимся своими новейшими мыслями и полезными уроками из мира высокотехнологичных продуктов. Тут вы найдете примеры методик, описанных в книге (см. www.svpg.com/examples), и постоянно обновляемый список рекомендуемой литературы (см. www.svpg.com/recommended-reading).

Для начинающих менеджеров по продуктам мы время от времени проводим интенсивные тренинги — обычно в Сан-Франциско, Нью-Йорке и Лондоне. Наша цель — поделиться новейшими знаниями и информацией и рассказать о важном опыте, способном во многом определить их дальнейшую карьеру (см. www.svpg.com/public-workshops/).

Мы также предлагаем узкотематические мероприятия компаниям, которые считают, что для того, чтобы успешнее конкурировать с другими производителями высокотехнологичных продуктов, им необходимо изменить работу своих инженерно-технических и продуктовых подразделений.

На сайте www.svpg.com вы найдете больше информации о наших предложениях и больше узнаете о партнерах SVPG, предоставляющих эти услуги.

ПРИМЕЧАНИЯ

1. Методология Customer Development («Развитие клиента») была представлена Стивеном Бланком в 2005 году. Концепцию Lean Startup («Бережливый стартап») в 2011 году предложил Эрик Рис. Прим. ред.

2. Словосочетания продакт-менеджер, менеджер продукта, продакт используются в книге как синонимы. Прим. ред.

3. СЕО — здесь и далее генеральный директор компании. Прим. ред.

4. Используется и термин продукт с минимальной функциональностью. Прим. ред.

5. Издана на русском языке: Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели. М. : Альпина Паблишер, 2018. Прим. ред.

6. В России таких специалистов часто называют просто менеджерами проектов. Прим. ред

7. Глава Amazon Джефф Безос рекомендует приглашать на встречу или в группу столько участников, сколько вы можете накормить двумя пиццами. Прим. ред.

8. Теперь это называется Google Ads. Прим. ред.

9. В некоторых компаниях эта должность называется delivery manager (DM) или менеджер проекта. Прим. науч. ред.

10. Модель трех горизонтов роста предложена компанией McKinsey для оценки возможностей развития компании с учетом эффективности ее текущей деятельности. Горизонт 1 — это важнейшие направления бизнеса, которые в первую очередь ассоциируются с названием компании и обеспечивают наиболее высокие показатели прибыли и денежных потоков. Горизонт 2 включает в себя новые возможности развития, в том числе для растущих предприятий, которые способны обеспечить существенную прибыль в будущем, хотя для этого могут понадобиться значительные инвестиции. Горизонт 3 ориентирован на воплощение в жизнь тех идей, которые дают реальный шанс добиться увеличения прибыли в более отдаленной перспективе. Подробнее об этом см. Mehrdad Baghai, Stephen Coley, and David White. The Alchemy of Growth. N.Y.: Perseus Publishing, 1999. Прим. ред.

11. См., например: Дорр Дж. Измеряйте самое важное. Как Google, Intel и другие компании добиваются роста с помощью OKR. М. : Манн, Иванов и Фербер, 2018. Прим. ред.

12. Синек С. Начни с Почему? Как выдающиеся лидеры вдохновляют действовать. М. : Эксмо, 2015. Прим. ред.

13. Издана на русском языке: Паттон Дж. Пользовательские истории. Искусство гибкой разработки ПО. СПб. : Питер, 2019. Прим. ред.

14. Термин, который произошел от сочетания двух слов — «хакер» и «марафон». Однако термин не относится исключительно к хакерам и сегодня в основном обозначает марафон/форум разработчиков. Прим. ред.

15. Издана на русском языке: Кнапп Дж., Ковиц Б., Зерацки Дж. Спринт. Как разработать и протестировать новый продукт всего за пять дней. М. : Альпина Паблишер, 2019. Прим. ред.

16. В терминологии бизнеса заинтересованные стороны принято называть стейкхолдерами. Прим. ред.

17. Аналог подобного шоу в России — «Народный артист»; выходило на телеканале «Россия» с 2003 по 2006 год. Прим. ред.

МИФ Бизнес

Все книги
по бизнесу
и маркетингу:
mif.to/business
mif.to/marketing

Узнавай первым
о новых книгах,
скидках и подарках
из нашей рассылки
mif.to/b-letter

#mifbooks

НАД КНИГОЙ РАБОТАЛИ

Руководитель редакции Артем Степанов

Шеф-редактор Ренат Шагабутдинов

Ответственный редактор Наталья Шульпина

Литературный редактор Юлия Жандарова

Арт-директор Алексей Богомолов

Верстка обложки Наталья Майкова

Верстка Олег Бачурин

Корректоры Вита Галич, Татьяна Сковородникова

ООО «Манн, Иванов и Фербер»

mann-ivanov-ferber.ru

Электронная версия книги подготовлена компанией Webkniga.ru, 2020