Это долгий день, потому что на производстве случился «пожар». Мне нужно пройтись по вопросам соблюдения законодательства и информационной безопасности со своей стороны, чтобы убедиться, что мы понимаем последствия ошибки и исправления, потому что иногда исправление на самом деле может вызвать еще больше проблем.
Затем мы настраиваем нашу внутреннюю коммуникацию. Пока инженеры работают над тем, как мы будем выпускать исправление, я разбираюсь с тем, как мы будем сообщать об этом. Как только мы налаживаем информационную связь, у нас все успокаивается. Огонь потушен.
В этот момент я обычно оглядываюсь назад на день, прежде чем отойти от дел, и спрашиваю: «Сделал ли я сегодня то, что хотел, планируя ранним утром свой день?» Если нет, я подумаю о том, как это повлияет на мои дела до конца этой недели. Есть ли дела, которые мне надо расставить в новом порядке по результатам сегодняшнего дня? Так я смогу понять, как будет выглядеть мой дальнейший рабочий процесс.
На этом мой день заканчивается. Я готовлю ужин и провожу остаток вечера, не заглядывая в Slack.
Ключевые идеи
• Бизнес – это не ругательство.
• Менеджер продукта отвечает за создание ценности как для клиента, так и для компании, чтобы она могла существовать дальше.
• Управление продуктом требует глубокого понимания целевого рынка и продуманной стратегии захвата определенной его доли.
• Для нового продукта достижение «соответствия продукта рынку» – задача номер один, и пока вы этого не добьетесь, время, потраченное на добавление функций или исправление ошибок, будет потрачено впустую.
• Хорошие менеджеры продукта постоянно думают о клиентах (прошлых, текущих и будущих) и жадно ищут любую информацию о них.
• Одни менеджеры продукта лучше справляются с запуском продуктов, а другие – с внедрением улучшений в существующие продукты.
• Управление персоналом и программами – это огромная часть вашего продукта, и оно становится еще более важным по мере роста вашего лидерства.
• Бизнес также означает деньги.
• Для некоторых продуктов в роли клиента выступает бизнес.
Глава 6Анализ продукта: рост, вовлечение, удержание
Из всего того, что делают менеджеры продукта и чего обычно не делают UX-специалисты, наиболее чужд миру дизайна, пожалуй, анализ данных. Даже бизнес-аспекты управления продуктами, от которых у дизайнеров пробегает нервная дрожь, можно сформулировать знакомыми терминами и понять: решение проблем, разработка решений, отвечающих конкурирующим потребностям и так далее. Также верно и то, что многие опытные UX-исследователи, стратеги и дизайнеры взвешенно потребляют данные, разумно используют их для получения информации для своих процессов и признают ценность сочетания количественной информации с качественной.
Но… почти везде, даже среди UX-специалистов, которые полностью освоили анализ данных как инструмент в своей профессии, мы видим очень мало желающих проводить большую часть своего времени, уставившись в столбцы с числами, таблицы с данными или аналитическими моделями (не говоря уже о создании, тестировании и развертывании аналитических моделей). Очень немногие люди занялись дизайном или UX из любви к обработке чисел. Я не говорю, что их совсем нет, но они крайне редки.
Можно без преувеличения сказать, что менеджеры продукта иногда тратят немалую часть своего времени на анализ данных. В большинстве ролей по работе с продуктом определенно есть задачи и даже периоды времени, когда понимание данных – это дело почти на полный рабочий день. Для некоторых фанатов это на самом деле очень весело.
Живущий в данных
Я называю это «жить в данных». Вы могли бы назвать это «плаванием в аналитике» – глубоким погружением и обширным исследованием. Эта ежедневная практика погружения в свои отчеты в конечном итоге приводит к чему-то вроде ощущения данных, их зернистости, неоднородности, цикличности и других «мелких деталей» с почти внешними характеристиками.
ИСТОРИИ ИЗ ЖИЗНИ
Мэтт Лемей, соучредитель и партнер Sudden Compass, предлагает более гуманистический способ описания такого рода погружения: «Я называю это „жизнью в реальности вашего пользователя“. Однако важно помнить, что данные являются посредником для других явлений. Я видел, как многие менеджеры продукта проводят вечность за информационными панелями, но никогда по-настоящему не учатся непосредственно у своих клиентов».
Человек, который постоянно думает о продукте, будет просыпаться и проверять ежедневные показатели, часто заглядывать в метрику Полярной звезды, настроит оповещения, чтобы не пропустить, когда ключевые данные внезапно подскакивают и выходят за границы обычных показателей. Такой человек не будет удовлетворен пассивным использованием так называемой панели мониторинга, а вместо этого станет постоянно участвовать в интерактивной практике опроса, массирования, сведения и нарезки данных, чтобы выявить смысл, где бы тот ни прятался.
Или, по крайней мере, он будет пытаться выявить некоторые зацепки, намеки, которые стоит качественно исследовать, чтобы перейти от любопытствующего «что» к удовлетворяющему объяснению «почему», а от этого – к действенному «как».
Людей, занимающихся управлением программными продуктами, а особенно тех, кто имеет гуманитарное образование или художественные навыки, беспокоит следующий вопрос: «Насколько я должен быть подкован в технологиях?» Как обсуждалось в главе 4 «Инженеры спорят», всё зависит от роли, но обычно достаточно быть знакомым с техническими понятиями и ограничениями, нежели уметь самостоятельно создавать готовый к выпуску код или в одиночку проектировать архитектуру технической системы.
Но один технический навык, которым должны овладеть все менеджеры продукта, – это умение делать запросы в базах данных и манипулировать данными. Если вам повезет, вы будете работать с программой для анализа продукта, которая одним нажатием кнопки создает диаграммы, результаты и даже некоторую аналитику. Однако бывают случаи, когда вам просто необходимо «заглянуть под капот» и самому тщательно поработать с данными.
Возможно, вы даже захотите пройти курс обучения по MySQL или любому другому варианту SQL (Structured Query Language), чтобы изучить основы запросов к базе данных из командной строки. Это знание позволит вам задавать свои вопросы напрямую данным и не обращаться к инженерам за помощью в получении набора данных или к аналитику данных для настройки определенного вида в вашей программе, например в Tableau.
С появлением таких инструментов, как Airtable, которые значительно упрощают создание базы данных, импорт, манипулирование и запросы, предоставляя полный пользовательский интерфейс типа электронной таблицы с вкладками, вы можете обнаружить, что обходитесь вообще без ввода какого-либо SQL-кода в командную строку. Однако даже такие low-code или no-code решения помогут вам на начальных этапах и позволят вам как менеджеру продукта позаботиться о себе, когда дело дойдет до данных.
Обычный цикл обучения менеджера продукта выглядит так: вы отправляете продукт, функцию или исправление, а затем осознаете, что нужен «инструментарий» (точки в продукте, которые добавляются в код для сбора и анализа пользовательских и системных событий). Делаете его в следующем спринте, а пока первые несколько недель работы с вашим новым продуктом вы действуете вслепую.
Затем вы начинаете более серьезно относиться к инструментарию и добавляете пункт о его создании в свой шаблон спецификации. На этом этапе вам следует связать его с целями, которые вы пытаетесь достигнуть на проекте, и определить, как вы будете оценивать успех. Затем вы пообщаетесь с разработчиками, чтобы они включили этот инструментарий в следующий релиз, что станет огромной победой.
После этого вы, как правило, понимаете, что все еще бессистемно составляете каждую новую спецификацию и что вам нужно поработать с коллегами-инженерами и определить соглашения или внедрить систему, которая позволит применять инструментарий к любому событию и следовать правилам именования, прописанным в таксономии.
В конце концов это становится второй натурой: вы никогда ничего не создаете и не отправляете, не снабдив это полным инструментарием, совместимым с остальной частью вашего продукта.
! СВЕРХСПОСОБНОСТИ UX-ПРАКТИКОВ
Благодаря вашему опыту работы в UX у вас есть уникальные способности вести разговор от «что», найденного в данных, к «почему». И это можно сделать только с помощью качественного исследования. Если вы до конца осознаете необходимость в данных, вы вызовете гораздо больше доверия, когда будете объяснять, что нужно замкнуть петлю обратной связи и исследовать сигналы, а для этого пообщаться с людьми.
Оптимизация воронки
Один из наиболее распространенных способов изучения данных и получения информации о том, как заставить части вашего продукта работать вместе, называется оптимизацией воронки. Если вдуматься, то метафора воронки довольно странная. Она в основном визуальная, нежели логическая. Суть заключается в следующем: в большинстве онлайн-процессов (или даже в любых задачах, за которые берутся многие люди) существует последовательность шагов, и редко кто, сделав первый шаг, проходит весь путь до конца.
На каждом шагу, как правило, происходит выпадение пользователей. Конечно, это выпадение сильно варьируется. Некоторые шаги настолько просты или приятны, что 100 % людей с предыдущего шага проходят на следующий. Но, согласно приблизительному эмпирическому правилу, вы будете терять около 10 % от общего количества при добавлении еще одного шага к процессу.