Частые вопросы о продуктовом менеджменте

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

За что отвечает продакт-менеджер

PM отвечает за результат или за процесс?

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

Чем PM отличается от Product Owner?

Единого отраслевого разделения нет. В одной компании PO ведёт backlog и delivery, а PM — стратегию и discovery; в другой это одна роль. Полезнее договориться не о названии, а о правах на конкретные решения: кто выбирает outcome, управляет backlog, принимает компромисс по сроку и качеству и общается с бизнесом. См. PM vs PO.

Должен ли продакт писать требования, SQL и проводить интервью сам?

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

Discovery и доказательства

Сколько интервью достаточно?

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

Можно ли начать разработку без исследования?

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

Как понять, что проблема действительно важна?

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

Приоритеты и roadmap

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

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

Должны ли на roadmap быть даты?

Да, когда дата отражает реальное обязательство или окно возможности. В остальных случаях точная дата создаёт ложную уверенность: для исследовательских ставок полезнее горизонты Now / Next / Later, ожидаемый outcome и условия пересмотра. Подробнее — в outcome-roadmap.

Что отвечать стейкхолдеру на «когда будет фича»?

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

Метрики и эксперименты

Нужна ли каждому продукту North Star Metric?

Не обязательно. North Star полезна, когда один показатель действительно отражает регулярно получаемую клиентом ценность и связывает работу нескольких команд. Сложному портфелю может понадобиться несколько уровней метрик. В любом случае рядом нужны input-метрики и guardrails — см. North Star и inputs.

Что делать, если данных мало или им не доверяют?

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

Любую ли гипотезу нужно проверять A/B-тестом?

Нет. A/B-тест требует достаточного трафика, корректной рандомизации и стабильного измерения. Прототип, интервью, concierge-тест, технический spike или анализ исторических данных часто быстрее отвечают на ранний вопрос. Метод выбирают по типу неопределённости, а не по престижу доказательства.

Команда и организация

Кто принимает финальное продуктовое решение?

Это должно быть известно до конфликта. Product, Design и Tech совместно готовят варианты и последствия, но у конкретного класса решений должен быть один accountable-владелец. RACI помогает прояснить участие, если не превращать всех заинтересованных в обязательных согласующих.

Как понять, что команда стала feature factory?

Симптомы: успех измеряют количеством релизов, задачи приходят уже с решением, после запуска никто не проверяет эффект, а roadmap заполнен функциями без проблем и outcomes. Начните с одной инициативы и восстановите цепочку «сигнал → проблема → ставка → изменение поведения → бизнес-результат».

Когда нужен Product Ops или продуктовый офис?

Когда несколько команд регулярно теряют время на одну системную проблему: несовместимые данные, инструменты, стандарты, знания или портфельные зависимости. Централизация оправдана, если снижает это трение и не забирает у команд права на продуктовые решения. См. Product Ops и кейс продуктового офиса.