Сформулировать общую цель
Цель описывает желаемое изменение, а список функций лишь возможные средства. Например, для сервиса записи на занятия задачей может быть уменьшение числа незавершённых записей из-за непонятного расписания. Это ещё не означает, что обязательно нужен новый календарь. Сначала выясняют, где возникает затруднение и насколько оно существенно. Команда должна одинаково понимать, для какой группы пользователей решается проблема и какое наблюдение будет считаться улучшением. Без этого каждый участник может качественно выполнить свою часть, но общий результат останется несогласованным.
Сравнить варианты и цену отказа
Любое решение занимает время, которое нельзя одновременно потратить на другое. Поэтому приоритет оценивают относительно альтернатив. Для проблемы расписания можно изменить подписи, порядок отображения, фильтры или сам процесс формирования занятий. Варианты различаются ожидаемым эффектом, трудоёмкостью и уверенностью в предположениях. Числовая оценка полезна как способ сделать допущения видимыми, но не превращает субъективные ожидания в точные данные. Особенно важно отмечать зависимости: небольшая функция иногда требует большой предварительной работы, которая не видна из короткого описания.
Согласовать ограничения участников
Дизайнер может видеть проблему понимания, разработчик технический риск, поддержка повторяющиеся обращения, а коммерческая команда обязательства перед клиентами. Эти сведения дополняют друг друга, если обсуждение привязано к общей задаче. Продакт-менеджеру полезно собирать основания, а не только голоса за идею. При разногласии уточняют, что именно не совпадает: факты, прогноз эффекта, допустимый риск или цель. Разные причины требуют разных действий. Недостающий факт можно проверить, а конфликт целей нужно явно вынести на решение, не скрывая его в расплывчатой формулировке.
Проверить результат после выпуска
Появление функции в продукте означает завершение реализации, но не обязательно достижение цели. После изменения сравнивают поведение с исходным состоянием и смотрят на побочные эффекты. Если записей стало больше, но выросло число ошибочно выбранных занятий, улучшение неоднозначно. Для интерпретации учитывают сезонность, изменения аудитории и другие одновременные события. Полезно заранее определить дату проверки и возможные решения по её результатам. Тогда команда не забывает о первоначальном вопросе и не объявляет успехом любое положительное число.
Попробуйте на практике
Составьте записку о приоритетах для вымышленного сервиса записи на занятия.
- Опишите одну проблему пользователя и один наблюдаемый результат, который должен измениться.
- Предложите три разных решения и для каждого укажите ожидаемую пользу, усилия и главное неизвестное.
- Выберите вариант для первой проверки и объясните, почему два остальных пока отложены.
- Запишите по одному важному вопросу от дизайна, разработки и поддержки, не приписывая им готового согласия.
- Задайте показатель результата, показатель возможного вреда и условие, при котором решение потребуется пересмотреть.
Как проверить результат. Записка связывает приоритет с целью, показывает альтернативы и содержит план оценки после изменения, а не только перечень функций.
Частые вопросы
Продакт-менеджер должен придумывать все идеи сам?
Нет. Идеи и сведения приходят от пользователей и разных участников команды. Важнее организовать их проверку и сделать основания выбора понятными.
Можно ли однажды составить приоритеты и больше их не менять?
План зависит от известных условий. Новые сведения могут изменить оценку, но пересмотр полезно объяснять через конкретные факты и ограничения, а не через случайную смену настроения.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.