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

AВыбрать чат-бота как решение и закрыть обсуждение альтернатив, чтобы команда не тратила время на сравнение вариантов
BДобавить и чат-бота, и баннеры самообслуживания, чтобы удовлетворить обе стороны спора и не фиксировать охват релиза
CСфокусироваться на дизайне баннеров и не описывать критерии приёмки, чтобы оставить максимум свободы для итераций
DОписать проблему «время решения типовых вопросов», задать критерии успеха, выбрать охват и зафиксировать, что не делаем
Правильный ответ. Когда спор про решения, полезно вернуться к описанию проблемы и через него согласовать область охвата и критерии приёмки.

Разбор

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

Проверь себя · 1/2разбор после ответа
Вы пишете PRD на экспорт заказов. В документе есть разделы «область охвата» и «вне области». Что лучше всего записать во «вне области» для первой версии?
Тренировать продукт в Telegram

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