Менеджер по продукту · Решает, что компания должна построить дальше и почему, превращая потребности клиентов, бизнес-цели и технические ограничения в один общий план, которым никто больше не владеет.
Образ менеджера по продукту, рисующего на доске смелую концепцию, по большей части ошибочен. Большая часть работы — это непривлекательный синтез: чтение данных опросов и аналитики, написание документа, достаточно точного, чтобы инженер не мог его неправильно прочитать, и сидение на собраниях, где настоящая работа — заставить нескольких несогласных людей принять один план.
Мастерство, передаваемое внутри дисциплины, заключается не в одном инструменте, а в большей степени в привычках: как сказать «нет» хорошей идее, потому что в данный момент это неправильная идея, как написать спецификацию, которая выдержит контакт с реальным инженером, и когда следует доверять тому, что делает клиент, а не тому, что, по его словам, он предпочитает.
What the work demands
Приоритизация
90
Письменное общение
82
Влияние заинтересованных сторон
78
Анализ данных
75
Исследование пользователей
68
Техническая свобода
58
Приоритизация
Решение о том, что не создавать, — это самое важное ежедневное решение. Дорожная карта — это, как правило, длинный список хороших идей, которым менеджер по продукту решил отказаться.
Письменное общение
Спецификация, обновление дорожной карты или вскрытие должны быть достаточно точными, чтобы люди, не присутствовавшие в зале, могли правильно действовать в соответствии с ними.
Влияние заинтересованных сторон
Заставить инженеров, дизайнеров, менеджеров по продажам и руководителей следовать одному и тому же плану, почти не имея официальных полномочий над кем-либо из них, что часто называют «руководством без власти».
Анализ данных
Чтение данных об использовании и результатов экспериментов достаточно хорошо, чтобы отличить реальный сигнал от шума и понять, когда метрика используется, а не действительно улучшается.
Исследование пользователей
Общайтесь напрямую с клиентами и наблюдайте, как они используют продукт, а не полагайтесь только на то, что они хотят, согласно результатам опроса или подержанному аккаунту отдела продаж.
Техническая свобода
Достаточное понимание того, как работает базовая система, чтобы вести реальный разговор о компромиссах с инженерами, не обязательно имея возможность построить ее самостоятельно.
A day in the life
8–9Inbox, Slack и ночные метрики
Отслеживайте сообщения и проверяйте ночные информационные панели на предмет всего, что сломалось или неожиданно сдвинулось, до начала дневных совещаний.
9–11Стендапы и межкомандная синхронизация
Ежедневные встречи с непосредственной командой разработчиков, а также периодические встречи с руководителями проектировщиков, инженеров или зависимой командой для разблокировки работы и разрешения разногласий.
11–13Глубокая работа: характеристики и анализ
Лучше всего защищенный блок дня, посвященный написанию или пересмотру спецификации, анализу результатов эксперимента или подготовке документа для предстоящего решения.
13–14Обед
Настоящий отдых в хороший день; в плохом случае это исчезает в виде длительных встреч, сменяющихся друг за другом.
14–18Встречи и обзоры заинтересованных сторон
Самый тяжелый блок совещаний за день: обзоры планов, критика дизайна, звонки по продажам или клиентам, а также переговоры, которые решают, что на самом деле выйдет в следующем квартале.
18–8Нерабочее время (в основном)
Личное время, хотя неделя запуска или срочное обращение к клиенту могут вернуть менеджера по продукту обратно в Slack задолго до официального окончания рабочего дня.
The know-how
Craft knowledge practitioners actually pass on — not motivation.
01
Напишите проблему перед решением
Прежде чем предлагать какую-либо конкретную функцию, изложите проблему клиента и почему она важна простым языком — принуждение команды к согласию по проблеме сначала выявляет неправильные решения, прежде чем кто-либо напишет код.
02
Общайтесь с пользователями, а не просто опрашивайте их
Опрос расскажет вам, чего, по словам людей, они хотят; наблюдение за тем, как кто-то на самом деле пытается использовать продукт лично или через общий доступ к экрану, обнаруживает трудности, о которых они никогда не думали упомянуть.
03
Отправьте самую маленькую вещь, которая проверит реальный риск
Прежде чем создавать полнофункциональную функцию, сократите ее до наименьшей версии, которая проверяет предположение, которое, скорее всего, окажется неверным — иногда это одна кнопка, которая измеряет клики еще до того, как что-то за ней появится.
04
Заслужите авторитет, которого вам не дает звание
Задайте направление и примите окончательное решение, когда люди не согласны, но заслужите этот авторитет посредством подготовки и суждения, а не предполагая, что он связан с должностью — менеджер по продукту, не имеющий организационных полномочий, должен быть прав чаще, чем менеджер, который может просто отдать приказ.
05
Скажите «нет» в письменном виде и объясните, почему
Отказ от запроса на добавление функции незаметно порождает недовольство; написание одного предложения, объясняющего компромисс — почему в этом квартале это, а не то — превращает «нет» в решение, с которым люди действительно могут спорить или принять.
06
Не доверяйте показателю, который никто не может изменить
Если предлагаемый показатель успеха не изменился заметно после нескольких прошлых попыток его изменить, задайте себе вопрос, действительно ли это правильный показатель, прежде чем делать ставку на дорожную карту квартала по его изменению.
Tools of the trade
Аналитическая платформа
Такие инструменты, как Amplitude, Mixpanel или внутренняя панель мониторинга, превращают необработанные журналы использования в воронки и когорты, о которых менеджер продукта может реально рассуждать.
Трекер проблем и дорожных карт
Jira, Linear или аналогичный инструмент превращают список идей в приоритетный, видимый список задач, который могут видеть одновременно инженеры, дизайнеры и руководство.
Шаблон спецификации/PRD
Структурированный формат документа — проблема, цель, требования, крайние случаи, показатели успеха — который делает спецификацию достаточно разборчивой, чтобы инженер мог опираться на нее, не догадываясь.
Платформа A/B-тестирования
Такие инструменты, как Optimizely или внутренняя среда экспериментирования, позволяют команде отправлять две версии функции разным пользователям и измерять, какая из них на самом деле работает лучше.
Помощник по составлению ИИ
Такие инструменты, как ChatGPT или Claude, все чаще составляют первую версию спецификации, суммируют интервью с пользователями или синтезируют ответы на опросы, перемещая работу в сторону редактирования и оценки, а не ввода текста с пустой страницы.
How people fail at it
Особенность синдрома фабрики
Измерение успеха по количеству выпущенных функций, а не по тому, решила ли какая-либо из них реальную проблему, приводит к загруженной дорожной карте и продукту, который фактически не улучшается.
Создаем то, о чем просил самый громкий клиент
Рассматривать конкретный запрос одного громкого клиента как репрезентативную потребность, а не проверять, отражает ли он проблему, разделяемую значимой долей пользователей.
Пропуск «почему» в спецификации
Написание подробного списка требований без объяснения основной проблемы или цели лишает инженеров возможности принимать здравые решения, поскольку реальность неизбежно отклоняется от плана.