Як написати PRD (документ вимог до продукту) з AI (безкоштовний шаблон)

Документ вимог до продукту (PRD) — це короткий опис простою мовою того, що ви створюєте, для кого це, що це має робити і як ви зрозумієте, що це працює. AI значно прискорює написання: ви даєте йому чорнові нотатки, а він перетворює їх на структуровані розділи, історії користувачів і граничні випадки. Ваше завдання — надати рішення, які AI не може ухвалити: мету, обсяг і те, що виключається, — і перевірити, що він додав.

Цей посібник розповідає, що має бути в PRD, покроковий спосіб його скласти з будь-яким AI-асистентом, промпти для кожного розділу та шаблон для заповнення, який можна скопіювати.

Для чого потрібен PRD (і для чого він не призначений)

PRD відповідає на чотири питання:

1. Навіщо ми це будуємо? Яку проблему вирішуємо і для кого?
2. Що це має робити в першій версії?
3. Чого це ще не робитиме?
4. Як ми дізнаємося, що це спрацювало?

Це не технічний дизайн. Він не визначає, яку базу даних чи фреймворк використовувати — це належить до окремої технічної специфікації, якщо вона взагалі потрібна. Це також не маркетинговий бриф і не бізнес-план. Тримаючи PRD в межах поведінки продукту, ви робите його корисним для всіх, хто його читає: дизайнера, розробника, стейкхолдера, який погоджує документ, або AI-конструктора, що перетворює його на код.

Кому він потрібен

• Соло-засновникам, які хочуть зупинити розростання обсягу, поки воно не почалося.
• Невеликим командам, яким потрібне одне місце, де зберігається «що ми погодили».
• Тим, хто наймає фрилансера чи агенцію, адже чіткий PRD дає чіткіші пропозиції. Див. найняти розробника або створити з AI.
• Тим, хто будує з AI, бо історії користувачів і список даних із PRD дають кращі промпти, ніж неструктурований список побажань.

Що AI робить добре, а що ні

Найчастіша помилка — це перевернутий другий із кінця рядок: AI впевнено заповнює прогалини правдоподібними припущеннями про ваших користувачів. Усе, що він пише про користувачів, розмір ринку чи поведінку, сприймайте як питання для перевірки, а не як факт.

Крок 1: Випишіть усе, що знаєте

Перед тим як щось промптити, напишіть чорнові нотатки. Підійдуть і маркери. Охопіть:

• Проблему в одному-двох реченнях з точки зору користувача.
• Хто з нею стикається. Будьте конкретними: «фрилансери-бухгалтери з 10–40 клієнтами», а не «малий бізнес».
• Що вони роблять зараз замість цього (таблиця, листи, інструмент, який їм не подобається).
• Один результат, який зробив би першу версію успішною.
• Що ви вже знаєте, що не робитимете.
• Жорсткі обмеження: дедлайн, бюджет, має працювати на телефонах, має інтегруватися з інструментом, який ви вже використовуєте.

Якщо ви ще ні з ким не говорили про цю проблему, зробіть це спочатку. У як перевірити ідею застосунку є практичний спосіб. PRD, побудований на припущеннях, — це добре оформлене припущення.

Крок 2: Попросіть AI зробити першу чернетку

Вставте свої нотатки і попросіть чернетку у фіксованій структурі. Промпт, який добре працює:

Ось мої нотатки про продукт. Перетворіть їх на документ вимог до продукту, використовуючи саме такі розділи: Короткий опис, Проблема, Користувачі, Цілі та метрики успіху, Обсяг (у межах / поза межами), Історії користувачів з критеріями приймання, Дані, Права доступу, Граничні випадки, Відкриті питання. Тримайте до двох сторінок. Не вигадуйте фактів про користувачів чи ринок — де моїх нотаток немає, запишіть питання у розділі Відкриті питання.

Остання інструкція важлива. Якщо сказати AI відправляти невідоме у «Відкриті питання», а не заповнювати його, чернетка буде значно чеснішою.

Крок 3: Уточніть кожен розділ

Пройдіться по чернетці розділ за розділом. Ці уточнювальні промпти допоможуть:

Проблема і користувачі

Перепишіть формулювання проблеми в одному-двох реченнях з точки зору користувача. Жодних слів про рішення.

Якщо в описі проблеми згадується ваш продукт, він описує рішення, а не проблему.

Цілі та метрики успіху

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

Оберіть одну-дві. «Двадцять бухгалтерів користуються щотижня протягом місяця» — це вимірюється. «Підвищити продуктивність» — ні.

Обсяг

Перелічіть усе в цьому PRD, що можна перенести на пізнішу версію без порушення основного сценарію.

AI-інструменти схильні додавати функції. Цей промпт змушує їх робити навпаки. Будьте безжальними: більшість PRD першої версії занадто великі. Що таке MVP пояснює, чому маленькі перші версії вчать більше.

Історії користувачів і критерії приймання

Запишіть кожну вимогу як історію користувача («Як [користувач], я хочу [дію], щоб [результат]») з двома-чотирма критеріями приймання у формі Дано / Коли / Тоді.

Критерії приймання — це чеклист, за яким ви перевірятимете пізніше. «Дано заброньований слот, коли інший клієнт переглядає календар, тоді слот не показується» — це можна перевірити. «Бронювання працює добре» — ні.

Граничні випадки і права доступу

Для кожної історії користувача перелічіть, що відбувається з порожніми даними, некоректним вводом, повільним або невдалим мережевим запитом і користувачем, який не мав би мати доступу.

Тут AI дійсно допомагає. Він швидко помічає порожні стани та прогалини в доступі, які люди забувають.

Крок 4: Перегляньте як скептик

Прочитайте весь документ ще раз і перевірте:

• Кожне твердження про користувачів походить від вас або з дослідження, а не від AI.
• Розділ «поза межами» принаймні такий самий довгий, як розділ «у межах».
• Кожна історія користувача має критерії приймання, які хтось може перевірити без запитань до вас.
• Розділ даних перелічує кожен тип записів, які зберігає застосунок, і хто їх бачить.
• Відкриті питання мають відповідального і дату.
• Нічого технічного не прослизнуло, якщо це не справжнє обмеження («має працювати офлайн» — це вимога; «використати Redis» — ні).

Потім покажіть документ одній людині, яка користуватиметься продуктом або будуватиме його, і запитайте, що незрозуміло. Їхні питання — це і є прогалини.

Шаблон PRD для заповнення

Скопіюйте це в документ і замініть квадратні дужки. Видаліть розділи, які справді не стосуються вас.

Назва продукту: [назва] Відповідальний: [людина, яка ухвалює рішення] Статус: [чернетка / на перегляді / погоджено] — Остання зміна: [дата]

1. Короткий опис

[Два-три речення: що це, для кого і головний результат.]

2. Проблема

[Проблема з точки зору користувача. Що вони роблять зараз і чому це заважає.]

3. Користувачі

4. Цілі та метрики успіху

• Ціль: [результат, якого має досягти перша версія]
• Метрика: [як її вимірюватимете і цільове значення]
• Не ціль: [щось, що люди можуть припускати, але що ця версія не намагається робити]

5. Обсяг

У першій версії:

• [функція]
• [функція]

Не в першій версії:

• [функція і чому вона може почекати]
• [функція і чому вона може почекати]

6. Історії користувачів

Історія 1: Як [користувач], я хочу [дію], щоб [результат].

• Дано [контекст], коли [дія], тоді [результат].
• Дано [контекст], коли [дія], тоді [результат].

Історія 2: Як [користувач], я хочу [дію], щоб [результат].

• Дано [контекст], коли [дія], тоді [результат].

7. Дані

8. Права доступу

[Хто може входити, які є ролі і що кожна роль може бачити та змінювати.]

9. Граничні випадки

• [Порожній стан: що показується, коли даних ще немає]
• [Некоректний ввід: що відбувається з неправильним email або відсутнім полем]
• [Доступ: що відбувається, коли хтось відкриває сторінку, яку не мав би бачити]

10. Інтеграції і обмеження

[Платежі, email, наявні інструменти, дедлайни, бюджет, пристрої, на яких це має працювати.]

11. Відкриті питання

Від PRD до промптів

Добрий PRD майже напряму перетворюється на промпти для AI-конструктора застосунків:

• Короткий опис, користувачі і таблиця даних стають вашим першим промптом.
• Кожна історія користувача стає окремим наступним промптом.
• Кожен критерій приймання стає тим, що ви перевіряєте в попередньому перегляді.
• Список «не в першій версії» — це те, що ви ще не просите.

Будувати по одній історії та перевіряти її критерії приймання, перш ніж перейти далі, набагато надійніше, ніж вставити весь PRD і просити все одразу. Як писати промпти для AI-конструкторів застосунків детальніше розповідає про промптинг.

Поширені помилки

• Написати рішення замість проблеми. «Користувачам потрібна панель» — це рішення. «Власники не можуть побачити, які рахунки прострочені, не відкриваючи кожен» — це проблема.
• Немає розділу «поза межами». Без нього кожна розмова відкриває обсяг знову.
• Дозволити AI вигадувати користувачів. Персони, які вигадав AI, здаються справжніми, але такими не є.
• Метрики, які неможливо виміряти. Якщо ви не можете це порахувати, це не метрика.
• Ніколи не оновлювати. PRD, який більше не відповідає тому, що ви будуєте, гірший за відсутність документа. Тримайте дату «остання зміна» і змінюйте її, коли змінюються рішення.

Використання PRD з Mythex

Якщо ви будуєте в Mythex, можна вставити PRD прямо в чат. Початок у режимі Plan підходить для PRD: агент читає документ, пропонує підхід і чеклист кроків, який можна переглянути у вкладці плану, і починає змінювати файли лише після того, як ви натиснете Build. Також можна зберегти частини, які мають діяти завжди — аудиторію, бренд, правила — як знання проєкту, щоб не повторювати їх у кожному чаті. Документація чату пояснює режими Build, Plan і Ask, а шаблони — швидкий спосіб побачити, як може виглядати перша версія, перш ніж писати повний документ.

Запитання