Но это не отменяет желание заинтересованных сторон знать, когда новые вещи будут выпущены на рынок, а исполняющим лицам, скорее всего, будет сложно понимать презентации в ProdPad. Чем сложнее портфолио вашего продукта и чем сильнее они надеются на что-то вроде диаграммы Ганта, тем больше вероятность того, что вы окажетесь вынужденными принять (или, по крайней мере, «оценить») другой инструмент для дорожной карты, например Aha! (рис. 10.9).
Рис. 10.9. Если у вас сложная дорожная карта и вам приходится по-разному доносить ее содержимое, то вам поможет такой инструмент, как Aha! (но он может снова втянуть вас в борьбу «план релизов против дорожной карты»)
Aha! является мощным инструментом и позволяет работать с гораздо большим количеством уровней сложности, чем ProdPad. Его модель продуктов, проектов, эпиков и прочего может не совсем идеально соответствовать вашей таксономии продуктов, но он довольно податливый, и его можно адаптировать к разным сложным средам.
Этот инструмент также дает возможность представлять различные визуализации вашей дорожной карты. Это означает, что вы можете, например, создавать версию с наглядными иллюстрациями для слайд-шоу в отдел маркетинга или презентации продаж. В то же время вы можете работать с внутренней версией дорожной карты, которая «оставляет все как есть», включая внутреннее обслуживание, технический долг и другие неприглядные приоритеты, при этом она будет давать больше рабочих деталей.
В конечном счете вам нужно быть независимым от инструментов и уметь работать с тем набором, который есть в вашей мастерской. Если вы являетесь начальником или создаете собственную продуктовую организацию, у вас может появиться захватывающая возможность выбора инструментов для работы с продуктом, которые раскроют потрясающий потенциал вашей команды.
ДЕНЬ ИЗ ЖИЗНИ ПМ SAAS
Иэн Джонсон, руководитель/директор по продуктам Flow Commerce, Inc.
– В какой отрасли вы работаете?
– Электронная коммерция.
– Насколько зрелой является ваша организация (или как давно существует)?
– 4 года, 70 человек.
– Поделитесь тем, что поможет описать среду, в которой вы управляете продуктом.
– SaaS-продукты B2B.
– Как вы начинаете свой рабочий день?
– Проверяю электронную почту и каналы Slack.
– Как вы проводите бóльшую часть утра?
– Либо ознакомлюсь с ключевыми отраслевыми отчетами и данными о клиентах, либо отвечаю на специальные запросы.
– Чем заканчивается утро?
– Ежедневным стендапом.
– Когда вы делаете перерыв на обед?
– Около 12:30.
– Что вы делаете в первую очередь после обеда?
– Встречаюсь с заинтересованными сторонами, стейкхолдерами.
– Как вы справляетесь с авралом или незапланированной работой?
– Оцениваю серьезность, а затем решаю, исходя из контекста.
– Как вы проводите бóльшую часть дня?
– Участвую в совещаниях.
– Что вы делаете в конце рабочего дня?
– Завершаю работу, сосредоточиваясь на 1–2 часа.
– Вы работаете по вечерам?
– Почти всегда.
Ключевые идеи
• Дорожная карта говорит о целях, на которыми команда по продукту работает сейчас и планирует работать в будущем.
• Дорожная карта – это не план запуска.
• Дорожные карты лучше разрабатывать по трем временны́м горизонтам: «Сейчас», «Затем» и «Позже».
• В дорожных картах следует уделять внимание желаемым результатам, сгруппированным по темам, а не длинным спискам любимых мозолей и функциональности из списка пожеланий.
• Дорожная карта продукта отражает стратегию, которая, в свою очередь, является выражением более обширной стратегии организации.
• Вы можете владеть целой дорожной картой или только ее крошечной частью.
• Планирование дорожной карты требует тщательной систематической расстановки приоритетов среди идей, которые исходят из общей концепции, пользователей, данных и коллег.
• Вам нужно будет обосновывать свои приоритеты и добиваться одобрения дорожной карты.
• Дорожная карта требует постоянного внимания и подпитки, и вам нужно непрерывно держать заинтересованные стороны в курсе обновлений и изменений по мере развития приоритетов и изменения внешних обстоятельств.
• Потренируйтесь говорить «нет».
• Начальник все равно может отменить ваши решения.
• Иногда бывает полезно показывать вашу дорожную карту в разных форматах, в зависимости от того, кто ее запрашивает.
Глава 11Главный информационный архитектор
В зависимости от размера продуктовой команды и ее позиции в организации, должность руководителя команды может называться по-разному: директор по разработке программных продуктов, вице-президент продукта, директор по управлению продуктом и даже менеджер группы продуктов. Иногда должность называется «руководитель по продукту», в результате чего точный уровень остается неясным.
В некоторых организациях у руководителя по продукту или CPO (директор по разработке программных продуктов) есть коллега по дизайну – директор по взаимодействию (англ. Chief Experience Ofifcer, или CXO) или руководитель по UX (или дизайну), но эта должность (к сожалению для UX) – все еще скорее исключение, чем правило. Чаще всего и UX, и управление продуктом в конечном итоге сходятся на руководителе по продукту.
Поэтому если вы решите выбрать карьеру в управлении продуктом с опорой на ваш опыт в UX, то ваше продвижение по лестнице потенциально приведет вас к роли руководителя по продуктам, где вы будете (снова) управлять дизайнерами наряду с менеджерами продукта и, вероятно, некоторыми другими специалистами (в науке о данных и анализе, заботе о клиентах, возможно, даже некоторыми инженерами).
Главный секретный соус продукта
Когда интернет только появился, люди занимались информационной архитектурой (ИА), которую сейчас мы называем стратегией по пользовательскому опыту, исследованиями и дизайном. Со временем появились новые роли и должности (дизайнер взаимодействия, UX-дизайнер, дизайнер продукта), а работа ИА постепенно либо свелась к «разработке навигации» для веб-сайтов, либо ограничивалась информационно насыщенными средами, для которых требовались библиотечные навыки таксономии, онтологии, групп синонимов и все остальное.
Но попутно информационная архитектура опять заявила о себе как о самостоятельной дисциплине, которая сообщала важные вещи о понятиях пространства, воплощения, информации и поиска путей. Как обсуждалось в предыдущих главах, методы ИА по отображению систем в виде карты с целью раскрытия их концепций и смысла, а также предоставления целостной картины и рассказа о том, что на самом деле создает команда, оказываются важнейшими навыками, которые необходимо пускать в ход при управлении продуктом на каждом уровне.
Много лет назад, когда я работал на одного из моих наставников по продуктам, Мотти Шейнкера, и пытался перезапустить AOL (теперь окончательно поглощенную Yahoo и проданную компанией Verizon частным инвесторам), я сказал ему, что удивился отсутствию информационного архитектора в штате и даже в системе управления персоналом.
Мотти повернулся ко мне и спросил: «Хорошо, а сколько в компании должно быть информационных архитекторов?» Я подумал над этим вопросом, а потом ответил: «Хотя бы один».
Это навело меня на мысль, что кто-то в компании должен быть главным информационным архитектором, чтобы выполнять тяжелую работу по картированию пространства проблем/возможностей, а также смысла и назначения продукта в этой более крупной системе.
Существует много организаций, где никто не занимается этой работой для продукта или его портфолио в целом, даже если многие действительно хорошие UX-дизайнеры и ПМ разумно продумывают ИА и структуру своих конкретных функций и проектов. Если кто-то и берется за такую более масштабную историю, то, как правило, это руководитель по продукту (или иногда, естественно, руководитель отдела дизайна).
Кто-то должен взять на себя ответственность за когерентность продукта на самом высоком уровне. Информационный архитектор и консультант Хорхе Аранго так сформулировал это в своем подкасте Informed Life в 2020 году[53]:
«Где в рамках этой структуры [управления продуктом] есть место для когерентности между этими вещами? Особенно если они являются частью некой экосистемы или семейства продуктов. В конце концов, этим вещам нужно придать связность на каком-то уровне…
Мой любимый пример недостатка этой когерентности – Kindle. Я уже некоторое время пользуюсь Kindle для чтения книг, поэтому знаком с этой системой. И я пользуюсь Kindle на трех разных устройствах. У меня есть специальный ридер Kindle. Также Kindle установлен на моих устройствах iOS, iPad и iPhone. И еще я использую Kindle на своем Mac. Я обнаружил, что такие вещи, как структура навигации, отличаются на всех трех».
Эта декогерентность между версиями одного и того же продукта является следствием разрозненного влияния со стороны различных платформ, технологических стеков и пользовательских баз. Даже при попытке установить согласованную модель в семействе родственных продуктов возникают естественные трения. Какие-то команды возразят: «Да, но на моем устройстве это не так», или «Но у меня есть причины для этого», или «Так всегда было на нашей подплатформе. Вы купили нас и теперь пытаетесь сделать частью себя».
В компаниях, где все постоянно меняется, особенно в крупных организациях, почти невозможно обеспечить когерентность сверху вниз, но руководитель по продукту постепенно может привести систему в гармонию. Дон Рассел, информационный архитектор CVS Health, отметила:
«Я бы сказала, что декогерентность тоже порождается организационной структурой и внутренней моделью финансирования, особенно в компаниях/продуктах, где многие направления бизнеса живут под одним брендом. Например, в CVS Health мы предлагаем прививки от гриппа как в аптеке, так и в нашей MinuteClinic. Та же прививка, та же тема, даже то же место, но разные направления бизнеса. Поэтому в отсутствие главного архитектора, который „видит сквозь“ направления бизнеса и создает когерентность, мы получили два способа запланировать прививки в одном домене, возложив бремя ответственности за поиск и выбор на клиента».