Kitobni o'qish: «Продакт-менеджмент на практике. Руководство для первого рабочего дня и всех последующих»

Name: Продакт-менеджмент на практике. Руководство для первого рабочего дня и всех последующих
Author: Мэтт Лемей
ISBN: 978-601-08-4574-9

Мэтт Лемей

Shrift:

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

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

This translation is published and sold by permission of O'Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

⁂

Отзывы о втором издании

«Просто возьмите и прочтите эту книгу. С первой до последней строчки она посвящена трудным урокам, которые каждый день приходится усваивать продакт-менеджеру как при удаленной работе, так и в офисе. Если вы зарабатываете на жизнь созданием продуктов, здесь найдутся ответы на вопросы, которыми вы задавались на протяжении всей своей карьеры».
Скотт Беркун (Scott Berkun), автор книг «Making Things Happen»¹ и «The Myths of Innovation»²

«Продакт-менеджер – одна из самых востребованных профессий XXI века. Это также одна из самых непонятных специальностей, которая порождает разнообразные ожидания. Книга прекрасно иллюстрирует ожидания, требования и реалии этой профессии примерами из жизни. Она разрушает миф о том, что продакт-менеджмент – удел избранных, и превращает эту работу в систему приемов, доступных каждому. Я рекомендую эту книгу в качестве справочного пособия для всех нынешних и будущих продакт-менеджеров, независимо от того, в какой точке своего карьерного пути они находятся».
Пранита Парадкар (Praneeta Paradkar), директор, продакт-менеджер, компания Broadcom Software

«Эта книга – незаменимый компас в море неопределенности и компромиссов, которыми наполнена работа продакт-менеджера, стоит вам только осознать, что нет единого верного способа делать эту работу. На страницах книги Мэтт рассказывает о том, как достичь результата в реальных условиях, и подкрепляет каждый важный тезис историями от практикующих специалистов».
Мартин Эрикссон (Martin Eriksson), соучредитель компании Mind the Product и соавтор книги «Product Leadership»³

«Эта книга охватывает всю сложность и неопределенность, с которыми ежедневно сталкивается продакт-менеджер. Она не пытается свести управление продуктом к набору готовых схем. Напротив, это практическое руководство, составленное из реальных историй о том, как разные люди подходят к своей работе. “Продакт-менеджмент на практике” воссоздает непосредственный обмен опытом со старшими продакт-менеджерами в разных отраслях и организациях и преобразует его в краткие выводы и удобные чек-листы».
Петра Вилле (Petra Wille), автор книги «Strong Product People» и коуч по лидерству продукта

«Книга Мэтта обязательна к прочтению как начинающим, так и опытным продакт-менеджерам, инженерам, которые часто не очень хорошо ориентируются в этой сфере, а также руководителям, заинтересованным в поиске лучших способов расширения возможностей своих продуктовых команд и внедрения большего количества инноваций. Книга полна захватывающих реальных историй и содержит множество полезных советов и чек-листов. Это не сухой и скучный учебник, а книга, которая дает правдивое представление о сложностях профессии, об истинных условиях и ограничениях, в которых сегодня работают продакт-менеджеры. В ней прекрасно схвачена суть профессии – кропотливое налаживание связей между людьми. Обязательное приобретение для книжного клуба любой продуктовой организации!»
Шаарон А Алварес (Shaaron A Alvares), старший менеджер отдела Agile-поставки и трансформации, компания Salesforce

«Мэтт – один из самых ярких специалистов, мы часто беседуем с ним об искусстве управления продуктом. Эта книга позволила сделать наши беседы доступными для широкой публики, в ней Мэтт не только делится с читателем опытом, но и проявляет одно из лучших своих умений: способность мыслить шире и открывать новые пути для решения повседневных задач».
Адам Томас (Adam Thomas), директор, компания Approaching One

«Мэтт ЛеМей – главный “демистификатор” управления продуктом. Эта книга отражает его прагматичный подход к сложностям и неопределенности, сопровождающим всю карьеру продакт-менеджера. Мэтт понимает, что управление продуктом – трудная работа, которая усложняется необходимостью прийти к общей цели, сохраняя при этом человечность. Он дает нам конкретные советы о том, как прокладывать свой путь в этой среде. Как говорит Мэтт: “Привыкайте к неудобствам”. Я настоятельно рекомендую все книги Мэтта и очень рад видеть обновленное издание – свидетельство развития теории и практики нашей профессии».
Клифф Барретт (Cliff Barrett), вице-президент по продукту, компания ChowNow

Отзывы о первом издании

«Кажется, что невозможно освоить тонкости повседневной работы с продуктом без практики. Мэтт ЛеМей объединяет случаи из практики опытных менеджеров с теоретическими методами и приемами, чтобы помочь закрепить ключевые аспекты работы продакт-менеджера».
Эллен Чиса (Ellen Chisa)

«Это выдающееся практическое руководство по повседневной работе в управлении продуктом. Мэтт выделяет конкретные обязанности и действия, которые могут предпринять начинающие менеджеры, чтобы наметить, спланировать, выполнить и проконтролировать процесс разработки продукта. Эта книга должна стать основным пособием для любого начинающего продакт-менеджера».
Блэр Ривз (Blair Reeves), автор книги «Building Products for the Enterprise»

«Уникальность этой книги заключается в том, что она выходит за рамки профессиональной терминологии, изложение строится вокруг крайне действенных советов для решения практических задач управления продуктом. Читая главу за главой, я улыбался и кивал – настоятельно рекомендую книгу всем продакт-менеджерам».
Прадип ГанапатиРадж (Pradeep GanapathyRaj), вице-президент по продуктам компании Sinch и бывший руководитель по управлению продуктами компании Yammer

«“Продакт-менеджмент на практике” – это смелый и честный учебник от человека, который действительно знает свое дело и понимает реальные проблемы, с которыми продакт-менеджеры сталкиваются каждый день. Практические советы Мэтта ЛеМея пригодятся как опытным, так и начинающим менеджерам».
Кен Нортон (Ken Norton)

«Если вы хотите стать отличным менеджером продукта, вам нужно выйти за рамки схем и инструментов. Книга делает именно это – честно и открыто показывает реалии жизни продакт-менеджеров. С помощью множества реальных историй об успехах, неудачах и заблуждениях, с которыми сталкивается каждый продакт-менеджер, Мэтт напоминает нам, что создание хороших продуктов – это прежде всего создание хороших отношений.
Обязательно к прочтению для практикующих и будущих менеджеров или всех, кто заинтересован в создании отличных продуктов».
Крейг Вилламор (Craig Villamor), главный архитектор-проектировщик компании Stash и бывший вице-президент по продуктам в Salesforce

От издательства

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

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

О научном редакторе русского издания

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

Предисловие

Я помню один из первых случаев, когда я задалась вопросом, достаточно ли я хороша, чтобы быть продакт-менеджером⁴. Иногда я не могу вспомнить, куда положила ключи пять минут назад, но этот эпизод навсегда останется в моей памяти. Это был 2011 год, я прилетела в офис моей компании в Сан-Франциско. Я сидела в конференц-зале Монаднок-билдинг⁵ на пересечении улиц Маркет и Кирни в окружении лимонно-зеленых стен, серых диванов и с огромной белой доской от стены до стены. Мы обсуждали мой проект с двумя другими продактами, и они приводили меня в настоящий восторг тем, как говорили о своей работе – совершенно очаровательно и непринужденно. Они могли легко на память привести любую статистику для нашей отрасли или компании и навскидку ответить на вопросы типа «Сколько в мире настройщиков пианино?». Я хотела быть как они, даже если бы они приветствовали меня словами «Как оно, сестренка?», имитируя манеру чернокожих американцев, или демонстрировали мне загоревшую во время отпуска кожу и говорили: «Гляди, я почти такой же черный, как ты!» Я восхищалась ими и думала, что таким и должен быть настоящий продакт-менеджер – настолько знающим и излучающим столько уверенности, что люди, с которыми он позволил бы себе некорректное поведение, легко простили бы все его выходки.

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

«Показатель NPV⁶ кажется довольно низким, чтобы получить одобрение Грега, – на основании чего сделаны твои выводы?»
«Я бы не использовал показатель себестоимости (COGS⁷) – откуда ты его взяла?»
«Ты подготовила все счета-проформы⁸? Сколько версий?»
«Какие у тебя эпики⁹?»
«Ты говоришь, что работала над этим со службой поддержки. Ты же понимаешь, что они являются статьей расходов, – любое их участие увеличит затраты?»
«А это вообще ваше внутреннее дело, твое и твоей компании. Не думаю, что это поможет вам в конкурентной борьбе. Это же просто “гонка по нисходящей”¹⁰?»

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

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

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

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

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

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

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

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

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

Приятного чтения!

Наталья Уильямс. Март 2022 г.

Предисловие автора ко второму изданию

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

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

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

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

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

Мэтт ЛеМей. Портленд, штат Орегон. Март 2022 г.

Введение

Почему я написал эту книгу: мой первый день в продакт-менеджменте

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

«Я так рад, что наконец-то смогу погрузиться в эту работу, – сказал я ему. – Где последняя версия плана продукта? Каковы наши квартальные цели и KPI? И с кем мне поговорить, если я хочу лучше понять потребности наших пользователей?» Он устало посмотрел на меня и глубоко вздохнул. «Ты умный, – сказал он. – Сам разберешься».

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

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

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

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

Для кого эта книга

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

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

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

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

Как организован материал в книге

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

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

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

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

Для простоты я обычно называю людей, для которых вы создаете продукты, «пользователями», а иногда «клиентами». Не каждый продукт оплачивается непосредственно пользователями, но каждый продукт используется кем-то или чем-то. В некоторых случаях, например при продаже корпоративного программного обеспечения (B2B), ваш «клиент» может отличаться от «пользователя», и вам нужно будет понимать и учитывать потребности обоих. Если вам интересно узнать больше об этом различии и его влиянии на проектирование продукта, рекомендую прочитать статью Блэра Ривза «Управление продуктом для предприятия» (Blair Reeves, «Product Management for the Enterprise», https://oreil.ly/i3Jk7).

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

Истории практикующих менеджеров продукта

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

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

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

Раздел «Что делать»

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

Благодарности

Спасибо Мэри Треселер (Mary Treseler), Анджеле Руфино (Angela Rufino), Лорел Рума (Laurel Ruma), Мег Фоули (Meg Foley) и каждому сотруднику O’Reilly Media за то, что они превратили презентацию «очень громкой и амбициозной книги об управлении продуктом» в хорошую вещь.

Спасибо Аманде Куинн (Amanda Quinn), Сюзанне Маккуэйд (Suzanne McQuade) и еще раз Анджеле Руфино (Angela Rufino) за работу над вторым изданием.

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

Спасибо Наталье Уильямс (Natalia Williams) за «дерзость, терпение, смирение и стойкость».

Спасибо Михаилу Позину (Mikhail Pozin) за то, что он помог мне лучше задавать вопросы.

Спасибо Тиму Касасоле (Tim Casasola) за то, что он помог мне найти лучшие слова.

Спасибо Кену Нортону (Ken Norton) за пончики.

Спасибо Мартину Эрикссону (Martin Eriksson) за его заботу о сообществе.

Спасибо Роджеру Магуласу (Roger Magoulas) за то, что взял меня под свое крыло.

Спасибо каждому менеджеру продукта, который поделился со мной своими историями. И особая благодарность тем, кто помог мне упорядочить процесс сбора этих историй. (Друзья, amirite¹³?)

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

Спасибо Джошу Векслеру (Josh Wexler) за лучшие кофейные посиделки.

Спасибо Энди Вайсману (Andy Weissman) за то, что он дал мне шанс.

Спасибо Саре Мильштейн (Sarah Milstein) за то, что все это началось.

Спасибо Джоди Лео (Jodi Leo) за исключительно своевременный подарок, который вдохновил меня.

Спасибо Трише Ванг (Tricia Wang) и Санни Бейтс (Sunny Bates) за то, что показали мне силу истинной дружбы.

Спасибо маме за то, что научила меня ясно излагать мысли.

Спасибо папе за не всегда очевидную, но непоколебимую тягу к учебе.

Спасибо Джоан (Joan) за все, за каждый день.

Глава 1. Практика управления продуктом

Недавно я спросил Прадипа ГанапатиРаджа (Pradeep GanapathyRaj), вице-президента по продукту в компании Sinch и бывшего руководителя по управлению продуктом в Yammer, как бы ему хотелось, чтобы каждый новый менеджер продукта понимал свои обязанности. Вот что он ответил:

• выявите лучшее в членах своей команды;

• работайте с людьми, не входящими в вашу непосредственную команду, с теми, у кого нет прямой мотивации работать с вами;

• научитесь справляться с неопределенностью.

К своему третьему пункту он добавил: «Навык понимания того, что вам нужно, вероятно, так же важен, как и то, что вы делаете после того, как выяснили это».

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

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

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

Что входит в понятие «управление продуктом»

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

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

Одно из наиболее полезных описаний управления продуктами взято из превосходной книги Мелиссы Перри (Melissa Perri) «Escaping the Build Trap» (изд. O’Reilly). В этой книге Перри описывает продакт-менеджеров как посредников обмена ценностями между бизнесом и его клиентами. Осознав, насколько это большая, важная и сложная задача, вы начинаете понимать, почему управление продуктами может быть таким трудным. Итак, в чем же заключается повседневная работа по выполнению этой сложной задачи?

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

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

У вас много ответственности, но мало полномочий.
Ваша команда не успела вовремя запустить продукт? Ответственность ложится на вас. Продукт, которым вы руководите, не достиг своих квартальных показателей? И в этом случае ответственность ляжет на вас. Как менеджер продукта, вы тот, кто несет ответственность за успех или провал продукта, – независимо от того, насколько хорошо остальная часть организации делает свою работу.
Работать в такой ответственной должности довольно сложно, но что еще хуже, продакт-менеджеры редко имеют какие-либо непосредственные административные полномочия. Есть ли в вашей команде дизайнер, который категорически не согласен с направлением развития продукта? Или инженер, чье отношение оказывается токсичным для всей команды? Вам придется решать эти проблемы, и вы не сможете сделать это с помощью угроз или приказов, так же как не сможете справиться в одиночку.
Если что-то нужно сделать, это часть вашей работы.
Фраза «Но это не моя работа!» редко звучит из уст успешного менеджера продукта. Независимо от того, входит ли это формально в ваши обязанности, вы несете ответственность за то, что должно быть сделано, чтобы обеспечить успех вашей команды и вашего продукта. Это может означать, что вы приходите пораньше, чтобы принести кофе и завтрак перегруженной работой продуктовой команде. Это может означать ведение напряженных переговоров с высшим руководством для разрешения неопределенности в отношении целей вашей команды. А может означать обращение за помощью к другим подразделениям, если ваша команда не имеет возможности самостоятельно выполнить работу.
Если вы работаете продакт-менеджером в очень молодом стартапе, возможно, что большую часть своего времени вы проведете, занимаясь тем, что, как вам будет казаться, имеет мало общего с «управлением продуктом». Мои знакомые продакты молодых стартапов занимались ad hoc управлением¹⁴ сообществами, руководили службой персонала, разрабатывали UX¹⁵ -дизайн, выполняли роль офис-менеджеров. Если нужно что-то сделать и это не входит в круг обязанностей другого человека, то – сюрприз! – это придется делать вам. Даже в крупных компаниях почти наверняка будут периоды, когда вам нужно будет взять себя в руки и сделать то, что официально не является вашей обязанностью. И поскольку вы несете ответственность за эффективность вашей команды и продукта, фраза «Это не моя работа» звучит одинаково неубедительно и в корпорации из списка Fortune 500¹⁶, и в стартапе из пяти человек.
Ну и для полноты картины заметим, что основную часть из того, что вам придется делать, нельзя сделать в одиночку. Вы не сможете позволить себе исчезнуть на несколько недель и, прочитав стопку книг, вернуться полностью подготовленным, чтобы самостоятельно создать продукт. Вам нужно будет просить окружающих людей потрудиться, поддержать и научить вас – часто людей вне вашей непосредственной команды, у которых может не быть очевидной причины, чтобы помогать вам.
Вы в центре событий.
Продакт-менеджер, как правило, оказывается в центре всех событий – он увязывает потребности бизнеса и цели пользователей, улаживает разногласия между инженерами и дизайнерами, согласует долгосрочную стратегию компании с повседневными продуктовыми решениями. Успешное управление продуктом выражается в сотнях ежедневных контактов с людьми, ведь именно люди реализуют далекие перспективы, обладают необходимыми навыками и достигают поставленных целей. Вы должны уметь ориентироваться в их стилях общения; знать, что для них важно; различать то, что они говорят, и то, что они под этим понимают.
Даже в организациях, которые хорошо структурированы и систематизированы, которые декларируют свою беспристрастность и заявляют, что «ориентированы на данные», вы неизбежно в какой-то момент окажетесь в центре паутины невысказанного недовольства и неразрешенных конфликтов. Другие смогут спрятать голову в песок и «просто делать свою работу», а восстанавливать связи между сложными, живыми людьми будете вы.

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

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

Вы не начальник
Часто роль менеджера продукта описывают как «мини-CEO» продукта. К сожалению, большинство менеджеров такого типа, которых я встречал, больше хотели иметь этот почетный титул, чем связанную с ним ответственность. Да, как менеджер продукта, вы несете ответственность за его успех или неудачу. Но в этом вы целиком зависите от доверия своей команды и ее готовности работать. Это доверие можно легко растерять, если вести себя как большой босс.
Вы не создаете продукт самостоятельно.
Упоминание продакт-менеджера часто вызывает в воображении людей образ изобретателя или мастера, который своими творениями меняет окружающий мир. Того, кто хочет создавать нечто своими руками, глубоко разочарует, что управление продуктом подразумевает общение и координацию. Более того, если вы с невинным любопытством полезете в дебри технических и дизайнерских решений, вашим коллегам, которые создают тот продукт, которым вы управляете, это может показаться раздражающим проявлением микроменеджмента.
Это совершенно не означает, что вы должны проявлять нулевой интерес к техническим и проектным решениям своей команды. Искренняя заинтересованность в работе своих коллег – одно из самых важных качеств менеджера. Однако управление продуктом часто создает особые трудности тем, кто привык решать проблемы под девизом: «Ерунда, я просто пойду и сделаю это сам». Если вы, как и я, ненавидели групповые проекты в школе и стремились взять на себя как можно больше работы, то управление продуктом, вероятно, научит вас трудным и важным вещам – доверять, сотрудничать и разделять обязанности.
Вы не можете ждать, пока кто-то скажет вам, что делать.
Как я выяснил в свой первый рабочий день, на этой должности вам крайне редко будут давать четкие рекомендации и инструкции. Крупные компании, особенно с долгой историей управления продуктом, с большей вероятностью будут иметь от продакта определенные ожидания. Но даже в таких компаниях вам придется самим разбираться, что вы должны делать, с кем говорить и как эффективно общаться с конкретными людьми в своей команде.
Если вам непонятна директива высшего руководства, нельзя сидеть и ждать, пока ее вам прояснят. Если вы видите проблемы в макете, нельзя ждать, когда кто-то другой это заметит. Ваша задача – выявлять, оценивать, расставлять приоритеты и решать все вопросы, которые могут повлиять на эффективность команды, независимо от того, дано вам такое указание или нет.

Портрет хорошего продакта

Некоторые организации известны тем, что предпочитают определенный тип кандидатов на вакансию в отдел управления продуктом. Например, Amazon исторически отдает предпочтение обладателям MBA¹⁷, а Google – кандидатам с дипломом из области компьютерных наук (computer science) Стэнфордского университета. (До какой степени эти компании следуют своим предпочтениям, никто толком не знает.) Говоря простым языком, классический портрет менеджера продукта – это либо технический специалист с деловой хваткой, либо бизнесмен, который не будет своей некомпетентностью выводить из себя разработчиков.

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

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

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

И плохого…

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

Жаргонный жокей.
Жаргонный жокей (Jargon Jockey) хочет, чтобы вы знали: описанный вами подход имел бы смысл только в гибридной методологии Scrumban¹⁸, но совершенно неприемлем для сертифицированного Scrum-мастера 3-го уровня¹⁹. Если вам пришлось искать значение хоть какого-то из этих слов, Жокей в шоке от вашей некомпетентности – как вы вообще получили эту работу? Жокей дает определения одних неизвестных терминов через другие и, кажется, склонен использовать их тем чаще, чем выше ставки в разгорающихся противоречиях.
Служитель культа Стива Джобса (The Steve Jobs Acolyte)
Стив Джобс: «Думай иначе!»™ Этот тип любит откинуться на спинку стула и начать задавать громкие провокационные вопросы. Он хотел бы напомнить вам, что люди тоже не знали, что им нужен iPhone. Он приводит цитату про быструю лошадь²⁰ и добавляет, что не хочет создавать «более быструю лошадь». Служитель культа Стива Джобса не говорит, что ваши пользователи глупы – по крайней мере, вслух, – но считает, что они определенно не провидцы. В отличие от него.
Герой-одиночка (The Hero Product Manager)
Не бойтесь, Герой здесь, у него есть потрясающая идея, которая спасет всю компанию. Герою не особенно интересно знать, почему эта идея может не сработать или что она уже обсуждалась и изучалась миллион раз. Вы слышали о том, что делал Герой на своей предыдущей работе? Он сам сделал весь проект или, по крайней мере, бо́льшую его часть. И всё же люди в этой компании, похоже, не спешат предоставить Герою ресурсы или поддержку, чтобы выполнить все эти удивительные обещания.
Трудяга (The Overachiever)
У Трудяги обычно получается черт знает что. Вы в курсе, что его команда добавила к проекту пятьдесят новых функций в прошлом году? А вы слышали о том, как Трудяга заставил работать свою команду три ночи подряд, чтобы уложиться в график? Трудяга почитается руководством компании как человек, который может сделать много, но не совсем ясно, какую пользу это принесет для бизнеса или для пользователей. И вы не можете не заметить, что члены команды Трудяги выглядят довольно напряженными… те, что еще не уволились.
Мученик продукта (Product Martyr)
Ладно! Мученик продукта (рис. 1.1) все сделает. Если продукт не был запущен вовремя или не достиг своих целей, Мученик продукта берет на себя полную и безоговорочную ответственность за то, что он (опять) все испортил. Мученик продукта заявляет, что ему не составляет труда приносить кофе для всей команды каждое утро, но звук, с которым он припечатывает поднос из Starbucks к своему столу, кажется, чуть-чуть громковат. Мученик продукта неоднократно повторяет, что ценит работу выше всего остального в своей жизни, и все же он выглядит возмущенным и усталым каждый раз, когда вы приходите к нему с вопросом или проблемой.

Рис. 1.1. Мученик продукта в естественной среде обитания

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

Поскольку главное в управлении продуктом – налаживание связей и устранение проблем, то очень трудно определить количественно, каков фактический вклад менеджера продукта в общее дело. Разработчик написал 10 000 строк кода. Дизайнер создал тактильную и визуальную вселенную, которая всех поразила. Генеральный директор обладает прозорливостью, ведущей команду к успеху. А чего достиг ты?

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

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

Нет, вам не нужно работать 60 часов в неделю

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

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

В наиболее продуктивные и важные годы моей карьеры я работал с 10 до 16:00 почти каждый день, и да, это был быстро растущий стартап. С помощью некоторых чрезвычайно талантливых коллег (и отличного психолога) я смог расставить приоритеты в задачах, которые помогали моей команде достигать целей, и перестал беспокоиться о том, считают ли мои коллеги, что я недостаточно усердно работаю. Оказывается, никто (кроме меня) не следил за тем, как поздно я задерживался в офисе в пятницу вечером или как быстро я отвечал в Slack²¹ утром в воскресенье.

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

Как насчет менеджеров программ? Владельцев продукта?

Почти на каждом семинаре по управлению продуктами первый вопрос, который мне задают, – это что-то вроде: «В чем разница между менеджером продукта и (менеджером программ / владельцем продукта / менеджером решений / менеджером проекта)?»

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

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

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

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

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

Я предлагаю тот же совет, когда меня спрашивают о специализированных названиях ADPR, таких как «продакт-менеджер по росту» (growth product manager) или «технический менеджер по продукту» (technical product manager). У меня очень смешанные чувства по поводу растущей специализации ролей продакт-менеджеров. В лучшем случае эта тенденция может помочь внести чуть больше ясности относительно ожиданий от людей на определенной должности в конкретной компании. В худшем случае это может стать еще одним источником ложной уверенности, которая затмевает присущее продуктовым ролям обобщение. (Я уже слышал реплику «Ну, этот человек работал только продакт-менеджером по росту, думаете, он сможет быть обычным продакт-менеджером?», и я боюсь, что таких разговоров впереди еще много.)

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

Подводя итоги. Плавание в море неопределенности

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

Что делать

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

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

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

• Не зацикливайтесь на «типичном портрете» успешного сотрудника. Хорошие продакт-менеджеры могут иметь самый разнообразный опыт.

• Не позволяйте неуверенности превратить вас в карикатуру на плохого менеджера! Сопротивляйтесь желанию напоказ демонстрировать свои знания или навыки.

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

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

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

Глава 2. Ключевые навыки продакт-менеджера

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

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

Гибридная модель: UX/Tech/Business

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

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

Рис. 2.1. Диаграмма Венна для продакт-менеджмента из книги Мартина Эрикссона «What, Exactly, Is a Product Manager?» (https://oreil.ly/K6MZ3)

В начале этого года мне посчастливилось побеседовать с Мартином Эрикссоном, создателем этой знаменитой диаграммы, в рамках встречи (https://oreil.ly/cBEds) сообщества Mind the Product, созданного в том числе им самим. Эрикссон рассказал мне, что эта диаграмма родилась не из желания окончательно застолбить роль продакт-менеджмента для будущих поколений, а скорее из желания поделиться видением этой профессии:

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

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

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

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

Модель навыков продакт-менеджера CORE: Communication, Organization, Research, Execution²³

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

На своих семинарах по управлению продуктом, где присутствуют люди из самых разных компаний, первый вопрос, который я обычно задаю, звучит так: «Какие пять ролей в вашей компании вам нужно координировать и согласовывать между собой?» Было бы преуменьшением сказать, что я получаю весьма различные ответы. Некоторые называют разработчиков, дизайнеров и акционеров бизнеса. Другие вспоминают про маркетологов, продавцов, специалистов по анализу данных и сотрудников по комплаенсу. Третьи перечисляют роли, о которых я никогда даже не слышал, а четвертые просто большими буквами пишут слово «КЛИЕНТЫ».

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

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

• общаться со всеми заинтересованными сторонами (Communicate);

• организовывать работу своей команды (Organize);

• исследовать потребности и цели пользователей продукта (Research);

• выполнять ежедневные задачи для достижения целей команды (Execute).

Рис. 2.2. Модель навыков продакт-менеджера CORE

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

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

Общение

Ясность превыше комфорта.

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

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

Неслучайно самые неудобные моменты нередко оказывают наибольшее влияние. Дискомфорт является частым проявлением отсутствия ясности. Это важный сигнал, указывающий на то, что люди не понимают друг друга или что ожидания не были четко сформулированы. Как менеджер по продукту, вы не имеете права бояться дискомфорта; вы должны активно работать, преодолевая его, чтобы добиться ясности для себя и своей команды. Мы обсудим конкретные стратегии реализации принципа «Ясность превыше комфорта» в главе 4 «Искусство чрезмерной коммуникации».

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

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

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

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

• Даю ли я своевременные и осмысленные ответы всем заинтересованным сторонам, которые обращаются ко мне?

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

Организация

Станьте лишним.

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

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

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

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

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

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

• Если я спрошу любого члена своей команды: «Над чем ты сейчас работаешь и почему?», сможет ли он быстро и осмысленно ответить?

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

• Если конкретный процесс или система (либо их отсутствие) не приносит пользы, активно ли я работаю со своей командой, чтобы изменить этот процесс или систему? Либо, если мы не в состоянии напрямую изменить этот процесс или систему, предпринимаю ли я активные действия, чтобы изменить наш способ взаимодействия с ними?

Исследование потребностей и целей

Живите в реальности вашего пользователя.

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

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

Руководящий принцип исследования – «Живи в реальности своего пользователя!». У каждого продукта есть пользователь – будь то потребитель, другой бизнес или инженер, использующий API. Важные для вас вещи, такие как соблюдение сроков проекта, управление бэклогом продукта или отчет о прибылях и убытках, для них вообще не имеют никакого значения. У ваших пользователей свой собственный набор приоритетов, потребностей и проблем, наиболее критические из которых могут вообще не иметь прямого отношения к их взаимодействию с вашим продуктом. Самые успешные продакт-менеджеры, которых я встречал, понимают не только то, как пользователи взаимодействуют с продуктом, но и то, как продукт вписывается в их реальность. Когда они оценивают продукт конкурента, они спрашивают: «Что этот продукт может означать для наших пользователей?», а не «Как мы можем обеспечить те же функции?». Подробнее об обучении непосредственно у пользователей мы поговорим в главе 6 «Разговор с пользователями».

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

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

• Основано ли каждое ли решение по продукту, которое принимает моя команда, как на бизнес-целях, так и на потребностях пользователей?

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

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

Выполнение

Направьте все усилия на результат.

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

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

Поскольку ориентированные на результат менеджеры всегда соотносят усилия с целями и результатами, они готовы взять на себя работу, которая может выглядеть не слишком героической или престижной. Например, сбегать за утренним кофе, если это поможет выпустить продукт вовремя. Как говорит Кен Нортон: «Всегда приносите пончики» (https://oreil.ly/BN9Ak).

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

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

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

• Занимают ли стратегические цели и задачи моей команды центральное место во время переговоров и мероприятий (таких, как планирование спринта, написание историй и т. д.)?

• Распределяю ли я свое время таким образом, чтобы это отражало цели и приоритеты моей команды?

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

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

Как насчет хард-скиллов?²⁴

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

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

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

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

В статье под названием «Getting to Technical Enough as a Product Manager»²⁵ Лулу Ченг (Lulu Cheng) предлагает краткий и исчерпывающий ответ на этот вопрос:

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

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

Почему же до сих пор существует это представление о необходимости хард-скиллов (в частности, технических)? Вот несколько мифов, которые я хотел бы развеять.

Вам нужны хард-скиллы, чтобы завоевать уважение технических специалистов.
Мысль о том, что технари уважают только технарей, откровенно говоря, оскорбительна для них. Я встречал продакт-менеджеров, которые сначала изображали из себя разработчиков, чтобы завоевать доверие своих технических коллег, но позже только отталкивали их, когда пытались влезать в детали реализации. Как мы обсудим в главе 3, навыки общения помогут вам разобраться в сложных технических вопросах, с уважением относясь к опыту своих коллег и соблюдая конкретные условия своей организации.
Вам нужны хард-скиллы, чтобы ставить задачи техническим специалистам.
Здесь есть доля правды: если вы понятия не имеете, как работают технические системы, ваши разработчики могут сказать вам, что создание чего-то относительно простого займет миллион лет. Хотя если ваша команда откровенно лжет вам о том, сколько времени это займет, у вас есть более глобальная проблема. Продакт-менеджеры, ориентированные на результат, вдохновляют свою команду на быстрое получение впечатляющих достижений, и делают это не за счет манипуляций техническими деталями.
Вам нужны хард-скиллы, чтобы сохранять интерес и вовлеченность.
Абсолютно верно: продакт-менеджер, который не заинтересован в работе своих коллег, скорее всего, обречен на провал. Но знания и интерес – это разные вещи. Многие из наиболее технически подкованных менеджеров меньше всего заинтересованы в изучении нового и погружении в работу своих коллег. Лучшие продакт-менеджеры, независимо от их технических навыков, способны проявлять неподдельный интерес к технической стороне работы своих коллег и умеют создавать прочные связи между разработкой продукта, потребностями пользователей и бизнес-целями.
Вам нужны хард-скиллы, чтобы делать запросы к базе данных, писать документацию и вносить небольшие изменения в код.
Во многих случаях это на 100 % верно. В соответствии с идеей о том, что «если что-то нужно сделать, это часть вашей работы», продакт-менеджеры часто сталкиваются с задачами, которые требуют знания языков программирования, систем контроля версий или логики баз данных. Например, в небольшой компании менеджера по продуктам могут попросить внести незначительные изменения в код (например, обновить копию веб-сайта), не прибегая к помощи разработчика. Это, вероятно, потребует от менеджера по продукту некоторого базового знакомства с языком программирования, используемым его командой, а также с инструментами, применяемыми для развертывания кода.

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

Подводя итоги. Изменение отношения к управлению продуктом

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

Что делать

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

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

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

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

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

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

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

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

Глава 3. Проявление любопытства

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

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

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

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

Спустя несколько часов я получил спокойный прямой ответ. И в тот четверг мы выпили кофе – я бы даже не назвал это событие «встречей». Мы отлично побеседовали, обнаружили некоторые общие интересы (оказалось, что мы оба гитаристы и питаем любовь к Fender Jazzmasters!²⁶) и обменялись некоторыми инсайтами о нашей совместной работе. Оказалось, что он чувствовал такое же отчуждение от команды разработчиков, как и я от команды анализа данных. Трудно признать, но это отчуждение было создано полностью мной самим. Предполагая, что другим неинтересно, что я делаю, я создавал впечатление, что я не заинтересован в том, что делают они. Ой-ой-ой…

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

Проявление подлинного интереса

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

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

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

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

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

Как сбросить корпоративную шелуху
Амелия С., продакт-менеджер, крупная медиакомпания
Когда я перешла из небольшого технологического стартапа в крупную медиакомпанию, я была уверена, что в компании такого масштаба и размера все идеально налажено с точки зрения управления продуктом. Но очень быстро выяснилось, что это не совсем так. У крупных компаний есть видимость формальности, которой обычно нет у стартапов, но это не значит, что процессы там линейны и предсказуемы. В стартапах часто гораздо более откровенно говорят о своих проблемах: «Тут все плохо; давайте исправим». В крупной компании могут потребоваться месяцы, чтобы люди откровенно рассказали о проблемах, с которыми столкнулись. Построение доверительных отношений требует использования множества классических менеджерских трюков: пойти выпить кофе с коллегами, посидеть за бокалом, познакомиться с их работой и проблемами. Проявите открытость: «Я новичок; ничего не знаю. Расскажи мне о своих проблемах, и мы что-нибудь придумаем». Никаких сделок, никаких quid pro quo²⁷, никаких «ты – мне, я – тебе». Никаких ожиданий. Люди ценят такую искренность. Одна из трудностей в большой компании заключается в том, что руководители обычно не знают, что на самом деле происходит. Они получают отчеты от людей, которые выполняют работу. Но я поняла, что для того, чтобы достичь успеха, мне нужно иметь партнерские отношения с людьми в редакторском, дизайнерском и техническом отделах – коллективах со сложившимися связями внутри более крупной организации. У них есть знания об истории организации, которых нет у меня. Если вам предстоит встреча с отделом маркетинга, вам нужен кто-то, кто скажет: «Вот что происходит на самом деле». Вы должны знать, что контакты с людьми есть, что они активны.
Я была искренне удивлена тем, как много моей работы в крупной организации происходило в кулуарах. Я думала, что основные действия будут происходить в больших конференц-залах, но на самом деле оказалось важно заручиться поддержкой людей в неформальной обстановке.

Мышление роста

В своей новаторской работе по обучению и успешности профессор психологии Стэнфордского университета и автор нескольких книг Кэрол Дуэк (Carol Dweck) утверждает, что у людей бывает либо «мышление роста» (growth mindset), либо «фиксированное мышление» (fixed mindset). Люди с мышлением роста рассматривают свои провалы и неудачи как возможности для обучения. Люди с фиксированным мышлением видят свои неудачи как негативное отражение их внутренней ценности. Люди с мышлением роста воспринимают новые знания и навыки как шанс для развития. Люди с фиксированным мышлением чувствуют угрозу со стороны всего нового.

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

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

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

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

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

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

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

Дар ошибаться

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

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

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

Не уходить в защиту

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

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

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

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

Предлагайте варианты, а не аргументы.
Вступление в противоборство «да» и «нет» – это верный путь к оборонительной позиции, тогда как предлагая заинтересованным сторонам несколько вариантов, вы получаете возможность оценить и изучить различные пути решения, не создавая ощущения, что вы собираетесь «выиграть» или «проиграть» спор. Говорят, что умение отказывать является ключом к успеху в управлении продуктом, однако лучшие продакт-менеджеры, с которыми я работал, никогда не говорили «нет» – они просто предлагали несколько вариантов и помогали своим командам (и особенно руководству команды и компании) выбрать один, наиболее отвечающий текущим целям и задачам.
Если вы чувствуете необходимость сделать что-то по причине беспокойства или ради защиты, запишите это и пересмотрите на следующий день.
У всех нас бывают моменты, когда хочется воскликнуть «вот черт!», когда мы понимаем, что могли бы справиться с ситуацией лучше, выразить что-то более четко или задать вопрос, о котором забыли. Но действия, вызванные тревогой, не всегда полезны, и мы редко можем вдумчиво расставить приоритеты, когда нас накрывает волна адреналина. Я не раз отправлял отчаянное послание коллегам, которое на самом деле только ухудшало беспокоящую ситуацию или отвлекало моих коллег от более важных дел. За последний год или около того у меня появилась привычка: при возникновении тревоги сделать глубокий вдох и выдох и записать любые действия, которые я хочу предпринять, а затем пересмотреть их на следующее утро. Наутро около 90 % из них, как правило, оказывались крайне нецелесообразными.
Скажите: «О’кей, отлично», а разберитесь позже.
Иногда перестать уходить в защиту так же просто, как привыкнуть отвечать «о’кей, отлично» почти на любой вопрос или заявление, побуждающее к обороне… а затем уже разобраться. Те несколько секунд между «о’кей, отлично» и любыми последующими словами вполне могут разрядить напряженную ситуацию и указать более простой путь. Я особенно оценил пользу этой стратегии при разрешении напряженных моментов на больших встречах. Например, однажды я присутствовал на совещании, на котором продакт-менеджер представил работу своей команды большой группе ключевых стейкхолдеров, и тут один из разработчиков его собственной команды сказал: «Извините, я до сих пор не совсем понимаю, зачем мы это делаем». Менеджер по продукту застыл. «Отлично, – сказал он и добавил: – Я обязательно уделю некоторое время в конце этой презентации, чтобы снова пройтись по нашим приоритетам. Спасибо, что упомянули это!» Такой подход не только позволил не допустить полного срыва встречи, но и дал разработчику время остыть и собраться с мыслями, прежде чем он оказался бы в центре серьезного конфликта.
Просите о помощи
Один из самых надежных и важных способов избежать оборонительной позиции – это заранее просить помощи у окружающих. Этот подход может быть особенно значим, когда вы просите помощи у кого-то, с кем трудно работать, кто оказался упрямым, воинственным, высокомерным и т. д. Я был удивлен, насколько я смог улучшить свои отношения с такими людьми, просто обратившись к ним и попросив поделиться своими знаниями или помочь решить проблему. Я часто призываю продакт-менеджеров начинать рабочую неделю с составления списка людей, которые могут сорвать или неправильно понять свои задачи, а затем обратиться к этим людям и открыто и доброжелательно побеседовать с ними с глазу на глаз.

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

Разделять провал продукта и личный провал
Сюзанна Лопес (Susana Lopes), директор по продукту, Onfido
Первым продуктом, над которым я работала после университета, было приложение для iOS в растущем стартапе. В то время эта компания требовала, чтобы продуктовые команды брали на себя обязательства по выбору функций, которые они будут предоставлять в каждом квартале. Таким способом наша команда по продажам получала возможность продавать то, чего у нас еще не было. Пропуск срока сдачи в конце квартала означал нарушение обещаний перед клиентами, что было абсолютно неприемлемо. На этом первом этапе моей карьеры моей мантрой было: «Провал невозможен». Такая установка укоренилась во мне с раннего возраста; эта фраза была написана на магните, и я видела ее каждый раз, когда открывала дверь холодильника! В роли менеджера успех для меня заключался в своевременном выпуске требуемых функций.
На практике это означало, что я мучила своих коллег, держа их в комнатах по несколько часов, чтобы разбить месяцы работы на небольшие задачи, которые мы могли бы оценить. Я сокращала объем работ по мере приближения дедлайна. Я сводила нашего дизайнера с ума, беспощадно урезая ее макеты, чтобы упростить их реализацию и уложиться в сроки. А затем, когда в декабре у нас в компании мы устраивали тайного Санту, я пожинала плоды своего поведения в виде пассивно-агрессивного подарка: один из моих коллег подарил мне кружку с надписью «ДИКТАТОР».
Примерно через год после того, как я стала продакт-менеджером, мне предложили взять на себя наше приложение для Android. К этому времени я стремилась показать, что я научилась всему и переросла свою диктаторскую кружку. Девиз «Провал невозможен» неохотно уступил место другому: «Ранний провал – раннее обнаружение ошибки» (Fail fast, fail early). Мне еще не было понятно, как достичь этого на практике, но все лидеры мнений и посты в блогах говорили, что это единственный способ создания успешных продуктов, поэтому мне хотелось попробовать. Графики выпуска были заменены целями и ключевыми показателями. Я была готова к «раннему провалу», сразу исключив как можно больше ошибок.
Мы продолжали поставлять наш продукт, росли и всегда терпели сначала неудачу, проверяли удобство продукта для пользователя в процессе разработки, и все было здорово. Пока… значения показателей не замерли на месте. Мы продолжали итерации, пытаясь обслуживать более сложные сценарии использования, которые, по нашему мнению, должны были привести к нам новых пользователей, но ничего не работало. «Провал» случился слишком поздно. Наш продукт просто не достиг своих показателей роста, и я не могла понять почему. Разработчики действовали правильно, поставляя новые релизы почти каждую неделю, тогда как в нашей компании было нормой выпускать релиз раз в месяц. Дизайнеры делали новые макеты и общались с конечными пользователями. Должно быть, проблема была во мне. Мой продукт потерпел неудачу. Я неудачница. Я переживала бессонные ночи, плакала в ванной, однажды даже убежала в церковь, чтобы поплакать… хотя я не религиозна.
Я плакала не потому, что мой продукт потерпел неудачу, а потому, что чувствовала, что это я потерпела неудачу. Мое чувство собственного достоинства и ценность моего продукта были одним и тем же. Я не разделяла провал продукта и личный провал… и выгорала. Даже сейчас некоторые из продуктов, над которыми я работаю, внедряются и растут медленнее, чем мне хотелось бы. Но я больше не чувствую себя неудачницей. Чтобы поддерживать эмоциональную дистанцию, я стараюсь быть самым злостным критиком своего продукта. Я могу перечислить в мельчайших деталях, почему каждый продукт, которым я в настоящее время управляю, это сущий кошмар. Я могу признать, что даже самые успешные продукты, над которыми я работаю, не идеальны, и, что более важно, я понимаю, что они – это не я. Мои продукты служат определенной цели, и они в чем-то успешны и в чем-то неудачны. И это нормально.
Примечание: Эта история из феноменального выступления на конференции Jam! в Лондоне в 2019 году, вы можете и должны посмотреть ее полностью здесь: https://oreil.ly/wJdgE.

Спрашивать «почему» без слова «почему»

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

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

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

Поощрять любознательность

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

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

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

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

Подводя итоги. Любопытство – это ключ

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

Что делать

• Обратитесь к людям в вашей организации и скажите: «Мне интересно узнать больше о вашей работе».

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

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

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

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

• Предложите несколько вариантов, чтобы избежать битвы «за» и «против».

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

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

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

• Попробуйте переформулировать вопросы «почему» в «не могли бы вы показать мне как».

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

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

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

Глава 4. Искусство чрезмерной коммуникации

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

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

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

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

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

Спрашивать очевидное

Если существуют «десять заповедей» управления продуктом, то это «Good Product Manager/Bad Product Manager» Бена Горовица (Ben Horowitz) (https://oreil.ly/z3688), документ, составленный в форме небольшого обучающего курса для менеджеров по продуктам компании Netscape еще во времена первого интернет-бума. «Good Product Manager/Bad Product Manager» – это краткий и простой документ, имеющий важное значение: он излагает в исключительно четких терминах ежедневные обязанности продакт-менеджеров в данной конкретной организации в данное время. «Делай это, не делай то». В каждой компании должен быть такой документ, в котором внятно и доходчиво изложены обязанности и четко указаны модели поведения, которых следует избегать.

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

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

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

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

Говорить как есть: что, если на большой встрече нужно сообщить неудобную информацию
Джулия Г., старший продакт-менеджер, стартап среднего размера
Несколько лет назад я оказалась на большой встрече примерно с 50 моими коллегами из отделов, непосредственно связанных с рынком: вся наша команда по продажам, отношениям с клиентами и маркетингу. Во время этой встречи был поднят вопрос о функционале, которого ждали наши клиенты. Наш генеральный директор в корпоративном чате сообщил, что именно этот функционал уже поставлен клиентам, и просил нас распространить эту новость.
Тут была одна проблема: этот функционал был внедрен для некоторых наших каналов, но не для того, который мы обсуждали в данный момент. Наступил неловкий момент: стоит ли мне во время такой большой встречи вмешаться и сказать во всеуслышание, что функционал, который только что столь радостно анонсировал наш генеральный директор, на самом деле еще не готов для клиентов, которые его ждут?
Имея печальный опыт того, что бывает, если замалчивать такие вопросы, я принимаю решение высказаться: «На самом деле эта функция еще не работает в этом канале, но мы планируем ее внедрить в четвертом квартале». Тишина. У меня уже проблемы? И тут приходит новое сообщение от нашего генерального директора в чате компании: «Хорошо, спасибо, что сообщили мне».
В тот момент я почувствовала такую защищенность, которую никогда раньше не испытывала. Я недавно присоединилась к этой компании после работы в ряде молодых стартапов, где многое нужно было сделать «вчера». У меня развилась привычка слышать в каждом вопросе обвинение. Если кто-то спрашивал меня: «Эй, у нас есть такое?», я слышала это как «Почему у нас до сих пор этого нет?». Я всегда стремилась опережать ожидания, поэтому если кто-то только задавал вопрос, я чувствовала себя так, будто уже потерпела неудачу. Сообщить генеральному директору о том, что функция не готова, посреди большой встречи определенно было рискованным шагом. Его ответ заставил меня почувствовать доверие и силу.
Раньше я думала: «Если я скажу людям, что что-то займет много времени или не является первоочередной задачей, они подумают, что я плохо делаю свое дело». Теперь я стараюсь быть честной и сразу говорить, что происходит на самом деле, а не то, что они хотят услышать. Я не знаю, насколько этот переход является естественным при взрослении продакт-менеджера и насколько это работает в средах, где люди вдумчивы и внимательны друг к другу. Но я чувствую, что даже если бы я оказалась в менее поддерживающей среде, я все равно сохранила бы эту вновь обретенную уверенность в себе. Это некомфортно, но это делает меня более эффективной.

Говорить прямо

Несколько лет назад я получил неожиданное сообщение от руководителя около девяти часов вечера в четверг. Там было написано: «Привет, было бы здорово, если бы мы могли выгрузить наш новый релиз приложения для iPhone в App Store сегодня вечером!»

Я был озадачен. Что это было? Срочное требование? Дружеская, но низкоприоритетная просьба? Меня попросили что-то сделать прямо сейчас? Или мне просто показали сквозь 113-символьное окно представление этого человека об идеальном мире? В большинстве случаев я, вероятно, с видом мученика перетащил бы себя за компьютер, сердито отправил бы релиз приложения в App Store и преувеличенно-бодрое сообщение в ответ «КОНЕЧНО! БЕЗ ПРОБЛЕМ!!!».

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

«Привет, мне очень жаль, но я сейчас на концерте. Если нужно, я могу поехать домой и отправить приложение».

Голос на другом конце линии колебался.

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

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

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

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

В течение примерно десяти секунд я чувствовал глубокую гордость за то, что проявил такую прямоту. Затем я понял, что большинство просьб, с которыми я обращался к своим коллегам, тоже начинались с чего-то наподобие «Было бы здорово, если бы, или «Эй! Как думаешь, может быть, ты мог бы, или «ЭЙ, СЕГОДНЯ ХОРОШАЯ ПОГОДА, Я ЛЮБЛЮ СЭНДВИЧИ. А ТЫ? Кстати, я хотел узнать, есть ли у тебя время…».

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

Тяга к любым окольным путям, чрезмерным извинениям и общему самоуничижению сильна. Но это одинаково вредно и опасно как для вас, так и для вашей команды. Я прибегал к самоуничижению многие годы, чтобы избежать ситуаций, в которых я чувствовал, что люди могут разозлиться на меня. Когда я приходил в свою команду с известием о жестких сроках или новой задачей, я часто говорил что-то вроде: «Угадайте, кто пришел! А вот и я, ваш ПРОДАКТ-МЕНЕДЖЕР, принес всем еще один ВЕСЕЛЫЙ ДЕДЛАЙН!» Это был неплохой способ разрядить напряжение и показать, что я «часть команды». И в большинстве случаев мне удавалось вызвать хотя бы улыбку.

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

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

Не во всем виноваты вы, а результаты важнее намерений

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

Я принял этот совет близко к сердцу и смирился с участью Мученика. Забавным образом я ощутил облегчение. Если что-то шло не так в моей команде, я мог просто заявить: «ДА, это моя ВИНА, Я ХУДШИЙ» – и продолжить жить дальше. И на самом деле сказать так было намного проще, чем инициировать откровенный разговор о том, как вся команда могла внести свой вклад в достижение некачественного результата и какие шаги мы могли бы предпринять для достижения лучших результатов в будущем.

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

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

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

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

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

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

Отказ от самоуничижения
М. Л., продакт-менеджер, стартап со 100 сотрудниками
Я никогда не забуду момент, когда я понял, что самоуничижение больше не может быть частью моего подхода к управлению продуктами. Я был около месяца в особенно сложном проекте, где часто приходилось работать до поздней ночи и срочно что-то переделывать. Я чувствовал себя виноватым за то, что моя команда должна терпеть все это, и старался разрядить напряженность, для чего прибегал к чрезмерным извинениям и драматическому самоуничижению. Я говорил: «Знаю, я самый ужасный» и: «Да, я знаю, я виноват, но как же вы здорово разгребаете весь этот бардак, который я устроил!».
А потом неожиданно я получил электронное письмо от разработчика из моей команды, которое искренне удивило меня. Он был обеспокоен тем, как я говорил о своей работе. Он хотел знать, действительно ли я так плохо к ней отношусь? Неужели я действительно думаю, что мне нечего предложить? Сделал ли он что-нибудь, что заставило меня думать, что мой вклад не оценен командой?
Когда я начал писать ответ, мне стало ясно: на самом деле я не думал, что мне нечего предложить, и уж тем более не считал, что все, что происходит, – моя вина. Даже не осознавая этого, я использовал самоуничижение как пассивно-агрессивный и не совсем искренний способ сказать: «Пожалуйста, не ставьте под сомнение то, что я прошу вас сделать». Я просто не был достаточно уверенным или зрелым специалистом, чтобы открыто поговорить со своей командой о том, почему мы работаем допоздна и переделываем то, что уже сделали. И конечно, мне не хватало уверенности, чтобы вести открытый разговор с руководством компании о минусах и недостатках работы до поздней ночи и исправлений в последнюю минуту. Мне было проще сказать руководству компании: «ДА, КОНЕЧНО, ВСЕ БУДЕТ СДЕЛАНО!», а затем заявить своей команде: «ИЗВИНИТЕ, ребята, я НИЧТОЖЕСТВО».
Вот мысленное упражнение, которое я использую, чтобы помочь себе избавиться от этой привычки. Если я чувствую желание сделать самоуничижительный комментарий, я спрашиваю себя: «Если кто-то в моей команде прервет меня, чтобы сказать: “Эй, не надо так. Ты отлично справляешься, и мы уважаем твое мнение”, буду ли я чувствовать облегчение или раздражение?» Если ответ «облегчение», то я стараюсь провести открытую ретроспективу с моей командой, чтобы увидеть, есть ли какие-то другие скрытые проблемы, которые могут вызвать у меня чувство неуверенности в своей работе. Если ответ «раздражение», то я спрашиваю себя, какого трудного вопроса или разговора я пытаюсь избежать через самоуничижение, и я стараюсь набраться смелости, чтобы поднять этот вопрос или разговор перед командой.
За несколько лет практики избегания самоуничижения я научился гораздо лучше организовывать искренние беседы со своей командой о том, что на самом деле происходит и что мы можем с этим сделать. Конечно, теперь я сталкиваюсь с более сложными вопросами о том, почему мы делаем то, что делаем, или о том, как я принял конкретное решение. Но опыт ответов на эти вопросы помог мне стать лучше и, надеюсь, смелее.

Два самых опасных слова в управлении продуктом: «выглядит неплохо»

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

Чаще всего этот жест одобрения принимал форму краткого сообщения в духе «Получил» или «Спасибо, что прислали». И действительно, это было все, что мне нужно, – и в то время все, чего я хотел. Я думал, что если кто-нибудь позже не одобрит работу моей команды, я смогу использовать это «Получил» как доказательство своей правоты и с честью выйти из положения: «Я ОТПРАВИЛ ЭТО ВАМ МЕСЯЦ НАЗАД, И ОТ ВАС НЕ ПОСТУПИЛО НИКАКИХ ЗАМЕЧАНИЙ, А ЭТО ЗНАЧИТ, ТЕПЕРЬ НИЧЕГО НЕ НАДО МЕНЯТЬ!»

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

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

Я убедился, как полезно включать хотя бы один значимый выбор или один открытый вопрос в любое сообщение либо встречу, где я запрашиваю обратную связь или одобрение. Электронное письмо, в котором говорится: «Во вложении наша дорожная карта на следующий квартал. Дайте мне знать, пожалуйста, если у вас есть какие-либо замечания», может создать внешний вид прозрачности и сотрудничества, но это не защищает вас от вопросов типа «Что это такое и почему я не видел этого раньше?», когда вы уже начнете выполнять эту дорожную карту. Напротив, у вас гораздо больше шансов получить осмысленные ответы на письмо, в котором сказано: «Прилагаю дорожную карту на следующий квартал. Как вы увидите, мы рассматриваем два разных варианта спринтов 6–8. Не могли бы вы сообщить нам до конца пятницы, какой из них, по вашему мнению, будет более актуальным?» (Мы обсудим важность отправки по почте и в чате конкретных сообщений, содержащих сроки, в главе 13 «Попробуйте повторить это дома. Испытания и невзгоды удаленной работы».)

1.Беркун С. «Сделано. Проектный менеджмент на практике».

2.Беркун С. «Откуда берутся гениальные идеи? 10 мифов об инновации». СПб., издательство «Питер».

3.Бэнфилд Р., Эрикссон М., Уокингшо Н. «Лидеры продукта. Как лучшие в мире продакт-менеджеры создают команды и запускают крутые продукты».

4.Термины «продакт-менеджер», «менеджер продукта», «менеджер по продукту», «владелец продукта», «PM» (сокр. от product manager) или просто «продакт» взаимозаменяемы и используются в русском переводе книги как синонимы. То же самое касается названия области: «продакт-менеджмент», «менеджмент продукта» и «управление продуктом». – Примеч. пер.

5.Монаднок-билдинг – историческое 10-этажное офисное здание площадью 204 625 квадратных футов в центре Сан-Франциско, Калифорния. – Примеч. пер.

6.NPV, net present value (чистая приведенная стоимость, ЧПС, или чистый дисконтированный доход, ЧДД) – один из показателей при оценке инвестиционных проектов. – Примеч. пер.

7.COGS, cost of goods sold (стоимость проданных товаров, себестоимость реализованной продукции) – балансовая стоимость товаров, реализованных в течение определенного периода. – Примеч. пер.

8.Счет (инвойс)-проформа (лат. pro forma, формально, для формы) – предварительный счет, содержащий сведения о стоимости продуктов и услуг, которую нужно заплатить заказчику после выполнения работ. – Примеч. пер.

9.Эпик (epic) – термин из области методологий разработки и управления проектами (например, гибких методологий, или agile). – Примеч. пер.

10.Гонка по нисходящей, гонка уступок (англ. race to the bottom) – снижение налогов, социальных гарантий, торговых ограничений и государственного регулирования бизнеса в результате конкуренции, например, за инвестиции. – Примеч. пер.

11.BHAG (big, hairy, audacious goal), или большая дерзкая амбициозная цель – вдохновляющая, долгосрочная цель, которая в перспективе выводит компанию на новый уровень. – Примеч. пер.

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

13.Искаженное англ. «Am I right?» – юмористический способ произнести «я прав?», используемый в социальных сетях после высказывания мнения или шутки, чтобы побудить людей согласиться с автором. – Примеч. пер.

14.В менеджменте и политологии управление ad hoc, или ситуационное управление (в противовес или как дополнение к стратегическому управлению), – это управление сложными, неформализованными объектами и процессами. – Примеч. пер.

15.UX (user experience) – «пользовательский опыт». Может включать в себя навигацию по сайту или приложению, состав функций внутри цифрового продукта, понятный текст и т. д. – Примеч. пер.

16.Fortune 500 – список 500 крупнейших компаний США по размеру выручки, ежегодно составляемый журналом Fortune. Впервые такой список был составлен в 1955 году. – Примеч. пер.

17.Степень магистра по деловому администрированию. – Примеч. ред.

18.Scrumban объединяет две ведущие гибкие методологии, Scrum и Kanban, в один процесс. От Scrum в этом подходе используется стабильная структура спринтов, стендапов и ретроспектив. Она дополняется возможностями Kanban, обеспечивающими наглядное представление рабочих процессов и объемов незавершенных задач. – Примеч. пер.

19.PSM III, или профессиональный Scrum-мастер уровня III. Скрам-мастер поддерживает в команде культуру Scrum и следит за соблюдением ее принципов. – Примеч. пер.

20.Есть цитата, не вполне достоверно приписываемая известному конструктору автомобилей Генри Форду: «Если бы я спросил людей, чего они хотят, они бы сказали, что хотят более быстрых лошадей». – Примеч. пер.

21.Slack – корпоративный мессенджер. Запущен в тестовом режиме в августе 2013 года, публичный выпуск состоялся 12 февраля 2014 года. – Примеч. пер.

22.Ambiguously Descriptive Product Roles (ADPRs) – неоднозначно описанные продуктовые роли. Общее название должностей с похожими, плохо различаемыми названиями и нечеткими сферами ответственности. В число ADPR обычно входят «менеджер продукта», «владелец продукта», «менеджер программы», «менеджер проекта» и т. д. – Примеч. пер.

23.Общение, организация, исследование, выполнение задач. В оригинале присутствует также игра слов: CORE skills – «ключевые навыки». – Примеч. ред.

24.Хард-скиллы (hard skills) – профессиональные навыки и знания, необходимые для конкретной специальности. Софт-скиллы (soft skills) – навыки, связанные с личностными качествами: критическое мышление, креативность, способность к сотрудничеству и общению. – Примеч. пер.

25.https://oreil.ly/9xWpa.

26.Марка и модель электрогитары. – Примеч. пер.

27.Услуга за услугу (лат.). – Примеч. пер.

28.Выражение «машина Руба Голдберга» используется для ироничного обозначения устройства или системы, выполняющих очень простое действие чрезвычайно сложным образом. Эти машины получили свое название по имени американского писателя, карикатуриста и изобретателя Руба Голдберга (1883–1970). – Примеч. пер.

Bepul matn qismi tugad.