Два стейкхолдера спорят: поддержка просит внедрить чат-бота, маркетинг просит добавить баннеры самообслуживания. Жалоба пользователей одна: долго решаются типовые вопросы. Какой подход к PRD (Product Requirements Document) наиболее корректен?

AНачать с problem statement про время решения типовых вопросов, определить критерии успеха, затем выбрать scope решения и явно описать non-goals
BСразу выбрать чат-бот как решение и запретить обсуждение альтернатив
CСразу добавить и чат-бота, и баннеры, чтобы всем было приятно, не фиксируя scope
DСфокусироваться на дизайне баннеров и не описывать acceptance criteria, чтобы не ограничивать команду
Правильный ответ. Когда спор про решения, полезно вернуться к problem statement и через него согласовать scope и acceptance criteria.

Разбор

Если начать с решений, команда рискует выбрать самый громкий запрос, а не самый эффективный способ снять боль пользователя. Problem statement возвращает дискуссию к сути: что именно ломается и как измерим улучшение. После этого можно сравнить варианты по стоимости, рискам и влиянию, выбрать MVP scope и зафиксировать non-goals. Так PRD (Product Requirements Document) становится инструментом выравнивания и принятия решений, а не перечнем хотелок.

Проверь себя · 1/3разбор после ответа
Вы пишете PRD (Product Requirements Document) на экспорт заказов. В документе есть разделы scope и non-goals. Что лучше всего записать в non-goals для первой версии?
Тренировать продукт в Telegram

Ещё вопросы по теме «Постановка задачи и PRD»