Руководитель UX Питер Боерсма, который также имеет опыт в управлении продуктами, отмечает, что менеджеры продукта не принимают все окончательные решения. За дизайнерами остается последнее слово, когда нужно сделать критически важный выбор в UX. Инженеры должны быть ответственны за технические архитектурные решения, выбор фреймворка и так далее. У менеджеров продукта нет никакой монополии на принятие решений, и все же за какой-нибудь час они принимают решений больше, чем люди на других должностях.
Однако верно будет отметить, что в зрелой, обладающей полномочиями команде менеджер продукта организует принятие решений и обеспечивает, чтобы это происходило в сотрудничестве и привлечении знаний из смежных дисциплин.
Мэтт Лемей высказывает аналогичную точку зрения: «Хорошие менеджеры продукта привлекают к принятию решений других людей. Но мне доводилось видеть, как многие переходят на должности менеджеров продукта, потому что хотят быть „теми, кто принимает решения“, а потом мгновенно теряют доверие своей команды из-за того, что принимают решения в одиночку и ни с кем ничего не обсуждают. В любом случае я надеюсь, что люди, приходящие из UX, будут лучше понимать, что чувствуешь, когда тебя исключают из числа тех, кто влияет на процесс, и станут более внимательными партнерами в деле принятия решения».
Одна из самых сложных задач – это понять, что невозможно всегда принимать правильные решения. Вам необходимо примириться с тем фактом, что иногда вы будете ошибаться. Вам неизбежно случится принимать решения, которые не оправдаются или покажут, что другой выбор был бы лучше. Как сказал Клемент Као, соучредитель Product HQ: «Когда вы не принимаете решение, то на самом деле вы „решаете его отложить“. Многие начинающие менеджеры продукта полагают, что „если они еще не решили, то это не засчитывается против них“, но такое затягивание само по себе является скрытым решением со своими последствиями».
По разным причинам среди менеджеров продукта существует консенсус: даже если вы справляетесь, то все равно принимаете неправильные решения в 25–30 % случаев. Вам остается просто надеяться, что вы не совершите ошибку, которая погубит компанию. Основатель LinkedIn Рид Хоффман сформулировал одну из веских причин, по которой вам нужно освоиться с этой задачей. Он сказал, что если вас ни капельки не смущает продукт, который вы выпускаете, то вы слишком долго откладывали его выпуск.
То есть у вас не будет роскоши отслеживать каждый элемент данных и каждое мыслимое исследование вплоть до сведения критических реакций по каждому решению к минимуму, особенно когда вы принимаете буквально десятки решений в день.
Во всяком случае, современный процесс гибкой разработки предвидит эту проблему и акцентируется на «приблизительном согласии и работающем коде».
Еще одно значительное различие между менеджером и дизайнером заключается в том, что менеджер – это не дизайнер!
Хороший менеджер продукта заботится о дизайне, и эта роль действительно предполагает предоставление требований и других материалов для информирования дизайнеров, иногда управление дизайнерами и всегда организацию процесса и внедрение результатов дизайна. Но последнее, что нужно[24] дизайнеру – это менеджер продукта, который, желая помочь, рисует макеты или имеет несколько железобетонных идей о том, как это делать.
Хороший менеджер продукта будет защищать UX-практики, ценить и отстаивать дизайн, но при этом он будет следить, чтобы не вступать в область ответственности и не покушаться на прерогативы команды дизайнеров.
ИСТОРИИ ИЗ ЖИЗНИ
Когда я был старшим директором по управлению продуктом в CloudOn – стартапе, который мы впоследствии продали в Dropbox, – мы считали большой победой, если даже наши руководители разработки обсуждали технические решения, процесс или продукт в терминах UX и с апелляцией к улучшению пользовательского опыта.
Мы знали, что этот словесный поток может быть не более чем пустой болтовней, основанной преимущественно на личных представлениях о пользовательском опыте, а не на тщательном исследовании, результатах тестирования и так далее.
Однако это было стартовой площадкой для продолжения диалога о том, как лучше создавать программное обеспечение.
В то время я также руководил работой по UX. Но UX отчитывались именно мне не только поэтому (как это часто бывает у руководства по продукту во многих технологических компаниях), а потому, что у меня в то время не было лидера в команде, который мог бы поспорить о лучшем пути дальнейшего развития и тем самым помочь мне.
Я пытался усидеть на двух стульях – руководителя UX и директора по продукту. Я пытался, насколько мог, выделить разные точки зрения и сопоставить их. Но правда была в том, что способность видеть две стороны сводит дебаты на нет – это напоминает игру в карты с самим собой. Я всегда знал, что я в действительности думаю и хочу сделать. На самом деле мне очень был нужен сильный UX-лидер, с которым можно было бы поспорить и добиться лучших результатов. Однажды на встрече кто-то в очередной раз привел доводы в пользу того, что нужно делать или не делать, исправлять или нет, ссылаясь на пользовательский опыт, и тогда я поймал себя на том, что отвечаю: «К черту этот пользовательский опыт», – в том смысле, если кратко, что мы не могли позволить себе возиться с этой чертовой штукой и нам нужно было сдать проект, несмотря на этот недостаток.
Но меня шокировал мой ответ.
Правда в том, что UX – это роль для идеалистов, пуристов, искателей и революционеров. Таким людям сложно идти на компромисс.
Менеджеры продукта не могут позволить себе роскошь чистоты и несгибаемого идеализма. У них тоже есть идеалы. И ценности. У них есть метрика Полярной звезды и много эталонов. Но большая часть работ в управлении продуктом – это достижение баланса между конкурирующими приоритетами без потери из виду своей миссии.
Развивая эту мысль дальше, Мэтт Лемей подчеркивает: «Идея о том, что вам придется отказываться от чистоты одной точки зрения, уметь синтезировать и идти на компромисс, очень важна, но недостаточно обсуждается», – и я думаю, что он прав.
Это правда, что сейчас менеджеры продукта все еще составляют диаграммы, решают проблемы и так далее, но если ваша страсть – передвигать пиксели и вы счастливы посидеть в Sketch или Figma, то учтите, что большинство менеджеров продукта или проводят очень мало времени в дизайнерских программах, или совсем там не бывают.
Если вы относитесь к такому типу дизайнеров, которые никогда не боялись управления в своей области и получали творческое удовлетворение от привлечения к делу команды талантливых специалистов и от коллективного объединения их лучшей работы для создания чего-то потрясающего, тогда, возможно, вы не почувствуете себя обделенным, убрав руки от управления пикселями.
► СВЕРХСПОСОБНОСТИ UX-ПРАКТИКОВ
Когда я стал настоящим руководителем по продукту, самым серьезным возмездием для меня стало, пожалуй, то, что конечный результат всегда отличался от того, что я лично мог бы выдать, если бы все решения оставались за мной. В конце проекта ни одна хорошая идея не остается неизменной, поэтому теперь, к счастью, я рассматриваю все как комплексный, целостный процесс, где конечный результат часто превосходит все, что я мог бы самостоятельно себе представить.
Многие специалисты, которые пришли из UX, уже освоили синтез целостных решений, учитывающий множество взаимосвязанных сил, потребностей и перекрестное давление.
Погрузитесь в это! Эта позиция неизбежно вступит в противоречие с какой-либо очень сильной точкой зрения или экспертизой. Отдел продаж, служба поддержки клиентов, генеральный директор, отчеты о данных, обзоры в App Store и дорожная карта могут одновременно кричать о совершенно разных «очень важных вещах». Как менеджеру продукта, вам придется выбирать самостоятельно, а затем иногда разочаровываться.
Дизайнеры проводят свои дни в исследованиях, набросках, придумывании идей, критике, создании прототипов, тестировании и так далее. Менеджеры по дизайну выполняют художественное руководство и другие функции по разработке стратегии дизайна и лидерства, такие как управление карьерой и профессиональным развитием дизайнеров и так далее.
Менеджеры по продуктам, напротив, пишут электронные письма. Они посылают сообщения в Slack. Они пишут спецификации. Пишут заявки. Они пишут примечания к релизу. Упорядочивают список задач. Обновляют дорожные карты и описывают, как результаты последнего квартала будут представлены начальству. Они разговаривают с клиентами. Они копаются в базах данных. Они потребляют отчеты с данными как воду. Они лежат без сна по ночам, беспокоясь о каждой мелочи.
Гистограмма навыков UX и ПМ
Пользовательский опыт и управление продуктом – это дисциплины «болтунов». Они обе берут свое начало из множества источников, являются синкретичными и охватывают различное подмножество навыков и склонностей в зависимости от команды и от личности специалиста. Будет полезно составить «гистограмму навыков», чтобы оценить себя, непосредственных подчиненных, потенциальных сотрудников и команды в целом.
Самый простой способ понять гистограмму навыков – это составить ее для себя. Во-первых, составьте список навыков UX, с которыми вы знакомы, и распределите их примерно от тактического (мастерство дизайнера и практическое исполнение) до стратегического (изобретательность, системное мышление и дизайн-исследования) концов спектра. Нет правильного и неправильного списка или порядка. На рис. 3.1 вы можете увидеть тактический список, который составил я. Ваш список будет отличаться от представленного, но выглядеть он должен аналогично.