PRD и документация

Документация — перевод продуктовых решений на язык команды. Пустая страница — главный враг: модель снимает «синдром первого абзаца» и делает первый проход за минуты, но автор документа остаётся продакт.

Что ИИ делает с документацией

собирает черновик PRD (Product Requirements Document — документ с требованиями к продукту) из ваших вводных: проблема, решение, метрики, риски;
раскладывает фичу на user stories с критериями приёмки;
ищет edge cases и неудобные вопросы к решению до разработки;
считает RICE (Reach, Impact, Confidence, Effort) и оформляет таблицу приоритизации;
приводит разнородные документы к единому формату.

Все формулировки — в библиотеке промптов, раздел про документацию.

Черновик PRD: проблема, решение, метрики, риски

PRD хорошо структурирован, поэтому удаётся модели. Но качество черновика целиком зависит от качества вводных: если скормить ей одну фразу «нужен экспорт в Excel», получится красивый документ, полный домыслов. Дайте модели контекст из дискавери: проблему с данными, сегменты, ограничения, гипотезы метрик. Откуда взять материал — в главе «Дискавери и исследования».

Готовый промпт — PRD:

«Ты — продуктовый менеджер. Собери черновик PRD по вводным ниже: проблема и зачем решать сейчас, целевые сегменты, решение на верхнем уровне, объём первого релиза и что не входит, метрики успеха с целевыми значениями, риски и открытые вопросы. Отдельно помечай места, где данных не хватает и нужно моё решение. Вводные: [вставьте]».

Ориентир по структуре черновика и что в каждом разделе проверять лично:

Раздел PRD	Что пишет модель	Что проверяет продакт
Проблема	Формулировку из ваших вводных	Что проблема подтверждена данными, а не интуицией
Решение	Описание на верхнем уровне	Соответствие стратегии, объём первого релиза
Метрики	Кандидатов метрик и цели	Реалистичность целей и связность с продуктом
Риски	Типовой список рисков	Специфические риски вашего контекста
Открытые вопросы	Формулировки	Ответы — их модель дать не может

PRD пишет продакт. Модель ускоряет первый проход — структуру, формулировки, типовые разделы. Но ответственность за решения в документе, от которого команда будет строить, лежит на авторе. Черновик, отправленный команде без вычитки, работает хуже, чем короткое письмо, написанное своими словами.

User stories и критерии приёмки

Разбиение фичи на истории — механическая работа, которую модель делает прилично: шаблон «как [роль], я хочу [действие], чтобы [ценность]» плюс критерии приёмки, по которым можно проверить готовность. Ваша задача — дать роли, объём и границы, а потом отредактировать: лишние истории убрать, размытые переформулировать.

Готовый промпт — user stories:

«Разбей фичу [описание] на user stories по шаблону «как [роль], я хочу [действие], чтобы [ценность]». Для каждой истории предложи 2–4 критерия приёмки в формате «готово, когда»: проверяемое условие, а не описание дизайна. Роли: [перечислите]. В первый релиз не входит: [перечислите]».

Критерии приёмки просите в проверяемой формулировке — так они превращаются в основу тест-кейсов и не превращаются в переписку на ревью.

Edge cases: где модель сильнее всего

Поиск нестандартных сценариев — самая недооценённая задача из зоны документации. Модель честно перебирает комбинаторику: пустые состояния, частичные данные, параллельные действия, потеря сети, таймзоны, права доступа. В команде на это редко хватает терпения, а необнаруженные edge cases регулярно оборачиваются багами и обращениями в поддержку.

Готовый промпт — edge cases:

«Ниже — описание фичи и user stories. Перечисли нестандартные сценарии и edge cases: пустые состояния, ошибки ввода, параллельные действия, потеря связи, права доступа, граничные значения. По каждому: сценарий одним предложением, что может пойти не так, вопрос, который нужно решить команде. Описание: [вставьте]».

Фильтруйте по вероятности и цене ошибки. Модель не различает «такое случается каждую неделю» и «такое невозможно в принципе». Она выдаст и экзотику. Это нормально: задача списка — не остаться в PRD целиком, а ничего не упустить до того, как решение согласовано.

Приоритизация по RICE

RICE — Reach × Impact × Confidence / Effort — понятен модели настолько, что она соберёт и таблицу, и аргументацию по каждой инициативе. Важная деталь от авторов фреймворка в Intercom: оценка — не автоматическое решение, а способ сделать компромиссы видимыми и обсуждаемыми. Модель считает по вашим числам; числа и допущения — ваши.

Готовый промпт — RICE:

«Ты — продуктовый менеджер. Сравни инициативы ниже по RICE: Reach (пользователей за квартал), Impact (шкала 0,25–3), Confidence (50/80/100%), Effort (человеко-месяцы). Посчитай балл, оформи таблицу, отсортируй по убыванию и отдельно выпиши допущения, из-за которых оценка может измениться. Если для оценки не хватает данных — помечай, а не придумывай. Инициативы: [вставьте]».

Что проверить перед отправкой команде

в PRD нет утверждений, которых не было в ваших вводных;
метрики связны с целями продукта и имеют реалистичные целевые значения;
каждая user story имеет проверяемые критерии приёмки;
edge cases отфильтрованы по вероятности и цене ошибки;
в RICE все числа ваши, а допущения перечислены явно.

После согласования документа начинается измерение — о нём в главе «Аналитика и метрики».

Источники

Intercom: RICE — Simple prioritization for product managers — оригинал фреймворка: факторы, шкалы и оговорка, что баллы не заменяют решений.
ProductPlan: Product Requirements Document — назначение PRD и его типовые разделы.
Atlassian: User stories with examples and a template — шаблон user story, три C и роль критериев приёмки.