Вопросы на собеседовании: Продакт-менеджер

Продакт-менеджер определяет, что и зачем создавать, опираясь на проблемы пользователей, цели бизнеса и технические ограничения, а затем помогает команде сосредоточиться на самой ценной работе.

• Он не управляет дизайном, кодом или людьми напрямую: PM отвечает за результат и ведёт команду через влияние, а не формальную власть.
• Ошибка начинающего PM заключается в попытке командовать инженерами и дизайнерами вместо поддержки команды и пользователей.
• На практике я бы ясно обозначал приоритеты и компромиссы, сохраняя за каждым специалистом ответственность за свою профессиональную область.

Я бы назвал конкретный продукт, например приложение для заметок, описал его пользователей, основную задачу и недостаток в реальном сценарии.

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

Я воспринимаю запрос на функцию как подсказку и с помощью вопросов выясняю, чего пользователь хочет достичь и почему текущий продукт ему мешает.

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

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

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

Jobs-to-be-done рассматривает продукт как инструмент, который человек выбирает ради прогресса в конкретной жизненной задаче, поэтому в центре внимания находится задача, а не демография или функция.

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

Персона пользователя представляет собой основанный на исследованиях собирательный профиль важного типа пользователей с его целями, поведением, трудностями и контекстом.

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

Сначала я бы сформулировал вопрос исследования, а затем выбрал подходящий метод: интервью для понимания мотивов, опрос для оценки распространённости и тест удобства для проверки выполнения задачи.

• Я бы поговорил с несколькими представителями целевой аудитории, задавал открытые вопросы об их реальном поведении и искал повторяющиеся закономерности.
• Цель исследования состоит в том, чтобы глубоко понять проблему до выбора решения.
• До рекомендации следующего шага я бы собрал повторяющиеся потребности, противоречия и открытые вопросы.

Хорошая функция решает реальную проблему, приносит пользу заметной части аудитории и улучшает важную для бизнеса метрику, не создавая лишней сложности.

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

Я бы оценивал не только долю запросивших функцию, но и состав этого сегмента, остроту проблемы, ценность пользователей и соответствие стратегии.

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

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

• Такая отправная точка удерживает команду на правильной проблеме и не позволяет преждевременно привязаться к любимому решению.
• Позже по ней можно проверить, действительно ли предложенная функция устраняет исходную проблему.
• Я бы сформулировал её без упоминания фичи и проверил с пользователями и по исходным данным.

Пользовательская история кратко описывает функцию с точки зрения пользователя в формате «Как [тип пользователя], я хочу [цель], чтобы [польза]».

• Например: «Как покупатель, я хочу сохранять товары в избранное, чтобы купить их позже».
• Такой формат удерживает внимание на том, кому и зачем нужна возможность, не переходя сразу к деталям реализации.
• Критерии приёмки я бы вынес отдельно, чтобы история оставалась краткой, а готовность можно было проверить.

Критерии приёмки задают конкретные условия, при выполнении которых функция считается готовой, обычно в виде чек-листа или сценариев «дано, когда, тогда».

• Они устраняют неоднозначность: инженеры понимают, что создавать, тестировщики знают, что проверять, а команда заранее согласует значение слова «готово».
• Без таких критериев ожидания выясняются после разработки, что приводит к спорам и переделкам.
• Я бы согласовал критерии с инженерами, дизайнером и тестировщиками до начала разработки.

PRD обычно содержит описание проблемы, целевых пользователей, целей и метрик успеха, границ задачи, основных сценариев, зависимостей и открытых вопросов.

• Документ помогает команде согласовать, что и зачем она создаёт, до начала подробного проектирования и разработки.
• Хороший PRD задаёт проблему и желаемый результат, но оставляет дизайнерам и инженерам свободу определить способ реализации.
• Я бы сделал документ кратким, назначил владельца и фиксировал решения по мере закрытия открытых вопросов.

Пользовательская история простым языком описывает, что и зачем нужно человеку, а техническая спецификация объясняет инженерными терминами, как это будет реализовано.

• История сохраняет связь с пользовательской ценностью, а спецификация переводит её в детали устройства системы.
• Как начинающий PM я отвечаю за историю и понимание проблемы, а спецификацию разрабатываю вместе с инженерами, не диктуя им решение.
• Я бы проверял, что каждое техническое решение связано с потребностью пользователя или критерием приёмки.

Definition of Done представляет собой общий список требований к любой завершённой работе, например проведённое ревью кода, тестирование, документацию и выполненные критерии приёмки.

• Этот стандарт определяет вся команда разработки, включая PM, чтобы поддерживать единый уровень качества и не объявлять работу готовой раньше времени.
• Он шире критериев приёмки, которые относятся к одной конкретной истории, тогда как Definition of Done применяется ко всей работе.
• Я бы пересматривал чек-лист, если повторяющиеся дефекты показывают, что командный стандарт качества неполон.

Я делю большую историю на небольшие сквозные части, каждая из которых приносит самостоятельную пользовательскую ценность и поддаётся проверке.

• Если историю трудно оценить из-за размера или размытости, её стоит разбить на части с отдельными и понятными результатами.
• Цель состоит в том, чтобы быстро завершать истории и учиться на результате, а не неделями ждать окончания огромной задачи.
• Я бы убеждался, что каждый срез можно выпустить или проверить, не дожидаясь всех последующих частей.

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

• Ссылка должна отправляться только на зарегистрированный адрес, действовать ограниченное время и позволять после сброса войти с новым паролем.
• Так потребность пользователя остаётся понятной, а точные условия готовности можно проверить.
• Я бы также обработал неверные и просроченные ссылки, не раскрывая, зарегистрирован ли указанный адрес.

В PRD я явно описываю не только успешный сценарий, но и пустые состояния, неверный ввод, сбои сети, отсутствие данных и другие ошибки.

• Раннее обсуждение таких случаев избавляет пользователей от непонятного поведения, а инженеров от догадок и неожиданных пробелов во время разработки.
• Я расставляю приоритеты по вероятности и тяжести последствий, поскольку не каждый редкий случай нужно закрывать сразу.
• Я бы разобрал самые рискованные состояния с дизайнером и инженерами и добавил их в критерии приёмки.

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

• Заранее заданное решение слишком рано ограничивает выбор и мешает найти более простой или эффективный подход.
• Метрика успеха даёт понятный ответ на вопрос, решена ли проблема после запуска.
• До выбора решения я бы сравнил варианты по целевой и предохранительным метрикам.

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

• Документ должен находиться в общем инструменте, которым пользуется команда, и регулярно появляться в обсуждениях и ревью.
• Если поддерживать его слишком трудно, вероятно, он перегружен деталями, поэтому я оставляю в нём проблему, границы и ключевые решения.
• Я бы назначил владельца и указывал даты решений, чтобы команда понимала, какая информация актуальна.