Книги для продакт-менеджера: от метрик к решениям

Книга нужна под продуктовое решение

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

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

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

Два направления чтения: поиск продукта и работа команды

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

Эта страница находится на сайте книги Егора Ганина «Как приготовить проект: Рецепты для создания успешных продуктов и команд». Для продакта в ней особенно полезна связка глав 3, 4, 5 и 7: цель, аналитика, выбор очередности и планирование. Она помогает разобрать ситуацию, когда направление понятно, но сведения и действия разных участников пока не складываются в согласованную работу.

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

Почему продуктовая метрика может вести к технической задаче

В главе 4 карта устроена по двум осям. Одна разделяет маркетинговые, продуктовые и технические данные. Другая — оперативные, тактические и стратегические показатели. При этом границы между направлениями проницаемы: время загрузки техническое по происхождению, но пользователь ощущает его напрямую.

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

Для выбранного показателя стоит записать определение, источник и период сравнения. Что считается началом оформления? Какие попытки оплаты входят в расчет? Не изменился ли способ сбора данных? Без этих договоренностей участники могут обсуждать разные величины под одним названием. Проверка качества данных предшествует выводам о продукте.

Пример: конверсия упала, а витрину менять рано

В интернет-магазине снизилась доля успешных оплат. Маркетинг предлагает обновить карточки товаров, продуктовая команда — сократить форму заказа. До выбора решения продакт вместе с аналитиком проверяет, на каком шаге изменилось поведение и какие группы пользователей затронуты. Это учебный пример: сначала требуется локализовать проблему.

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

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

Как превратить выбор в продуктовый план

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

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

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

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

Что попробовать после чтения

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

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