Вдохновленные Каган Марти

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

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

Отзывы

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

Аманда Ричардсон, директор по стратегическому развитию и управлению данными 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

Предисловие

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

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

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

Первое издание я писал, когда методология гибкой разработки продуктов, Agile, еще не вошла в практику продуктовых компаний так прочно и надежно, как теперь, а концепции Customer Development и Lean Startup[1] не были такими популярными, как сейчас. Сегодня многие команды используют их уже не первый год и больше интересуются выходящим за рамки подходов 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 схематически представлен процесс, который по-прежнему используют большинство компаний при создании продуктов. Воздержусь от разглагольствований и поучений – сначала просто опишу его.

Рис.0 Вдохновленные

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 7. Lean и Agile и не только

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

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

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

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

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

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

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

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

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

Глава 8. Ключевые идеи

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

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

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

Понятие продукта, безусловно, включает функциональность – функции и характеристики. Но сюда относятся и технологии,

Читать бесплатно другие книги:

Эта книга написана специально для новичков, делающих свои первые шаги в освоении профессии дизайнера...
Идеальные пары никогда не ссорятся, не устают, не раздражают друг друга и не существуют.Поэтому в но...
Самозанятые. Все о налоге для самозанятых. Кто может стать самозанятым? Какой вид деятельности выбра...
Автор книги Симона Дэвис, педагог Монтессори и основатель Монтессори-школы в Амстердаме, объясняет, ...
Раньше юноши мечтали отправиться в космос, а сейчас в моде ЗОЖ и историческая реконструкция. Вот и Я...
Книга рассказывает о событиях, происходивших в Галичине (австрийской Галиции) в годы Первой мировой ...