# AI-плейбук для Head of Product — discovery, specs, releases

> Як Head of Product у компанії 30-500 людей насправді має застосовувати AI у discovery, специфікаціях і релізах — без сповільнення команди й випуску slop'у.

- Автор: Ярослав Максимович (Founder & CEO, AI Advisory Board)
- Опубліковано: 2026-05-09
- Оновлено: 2026-10-26
- Джерело: https://aiadvisoryboard.me/uk/blog/ai-playbook-for-head-of-product

Якщо ви Head of Product, який читає 12 транскриптів інтервʼю на квартал і все одно відчуває, що відстає від сигналу — справа не в каденції discovery. Справа в тому, що 77% AI-роботи, яка допомагає продуктовим командам, невидима, розкидана по особистих акаунтах PM'ів і ніколи не доходить до вашої roadmap.

## TL;DR

- Head of Product має три AI-домени: discovery (сигнал), specs (ясність), releases (швидкість).
- Помилка — починати з code-gen для інженерів. Це плейбук Head of Engineering, не ваш.
- Шість плеїв нижче, два на домен, за віддачею та зворотністю.

## Чому продукт — місце, де AI-сигнал помирає

Stanford 2025 показав патерн: ~77% AI-вжитку в організаціях невидимі — на особистих акаунтах, у несанкціонованих інструментах, без повернення в команду. У продукті це означає: PM має геніальний ChatGPT-тред з синтезом 30 інтервʼю, а ви, Head of Product, його не бачите.

Робота Head of Product — не забороняти це, а вивести роботу в спільне світло. Потрібні санкціоновані інструменти й кілька структурних ритуалів. Не tool RFP.

> **Definition:** Discovery — структурований пошук сигналу про те, що насправді потрібно користувачам, до рішення про побудову. Не плутати з delivery.

## 90-денний product AI-плейбук (шість плеїв)

### Discovery — Плей 1: синтез інтервʼю з traceable цитатами

Кожен PM завантажує транскрипти (санкціонований tool, EU-region storage для ЄС) і запускає фіксований промпт: "5 тем. Для кожної: 3 verbatim-цитати з timestamp, кількість різних інтервʼюйованих, що її піднімали, + 1 спростовуюча цитата". Спростовуюча — магія. Вона змушує модель шукати докази проти теми, де більшість AI-summary провалюються.

```
Ти discovery analyst. З N транскриптів витягни:
- 5 тем (макс)
- Для кожної: 3 verbatim-цитати (ініціали + timestamp)
- Для кожної: count різних інтервʼюйованих
- Для кожної: 1 disconfirming або "no disconfirming evidence found"
НЕ вигадуй цитати. НЕ перефразовуй.
```

### Discovery — Плей 2: витяг JTBD

Той самий корпус, інша лінза: витяг verb-noun-context кортежів ("draft renewal email | коли клієнт мовчить 30 днів"). Список JTBD повертається PM-у і дизайнеру. Це вхід для наступного doubles-down у discovery.

> **Tool tip (Course for Business):** У нашій **6-week program** PM-и проходять **Shoulder-to-Shoulder** на своїх живих транскриптах. Бачимо first-week win'и, де PM до пʼятниці запускає синтез-промпт по своєму research backlog. Принцип — **Augment, don't replace**: PM володіє темою, AI робить механічну витяжку. [course.aiadvisoryboard.me/business](https://course.aiadvisoryboard.me/business).

### Specs — Плей 3: PRD-чернетка з discovery + JTBD

Після синтезу AI пише PRD skeleton: problem statement, target user, top 3 user stories, top 3 risks, out-of-scope. PM переписує. Виграш не у швидкості, а в тому, що перша чернетка вже не порожня сторінка, і PM критикує замість генерувати.

### Specs — Плей 4: інтерогатор промпт для пробілів

Будь-який spec — свій чи успадкований — пропускайте через "interrogator": "10 питань, які поставив би senior інженер перед estimate. Згрупуй за ambiguity, missing data contract, missing failure-mode". Це ловить більше дефектів, ніж peer-review templates, бо LLM безсоромно ставить очевидні питання, які ви побоялись би поставити.

### Releases — Плей 5: release notes, які людина читає

Класичний провал: інженерія пише 40 commit-summary, маркетинг переписує як "exciting new features", клієнти не вчаться нічому. Замінити: git log → сегментація user-visible vs internal → для user-visible 1-line "що змінилось" + 1-line "чому це важливо". PM підписує; маркетинг стилізує. Cycle time release notes падає з 4 годин до 30 хвилин.

### Releases — Плей 6: чернетка постмортему інциденту

Коли щось ламається у проді, постмортем помирає, бо ніхто не має 4 годин. On-call вставляє timeline + Slack-треди у санкціонований tool з фіксованим темплейтом. Інженерія редагує. Completion rate постмортемів приблизно подвоюється.

## Team scan (what AI champions report after week 1)

- Кожен PM запускає хоча б один synthesis-промпт на реальних транскриптах.
- 5+ JTBD-кортежів, які команда раніше не артикулювала.
- 1-2 specs переписані після interrogator-промпту.
- Cycle time release notes помітно падає (типово ~50%).
- 1 постмортем, який пропустили б, написаний.
- Head of Product вперше за місяці читає verbatim-цитати реальних користувачів.
- Раніше shadow PM-AI workflow занесений у санкціонований стек.
- Інженерія повідомляє менше "spec ambiguity" тікетів назад у продукт.
- 1 PM зізнається, що використовував особистий акаунт, і переходить на санкціонований.
- 1 дизайнер сам приєднується до discovery synthesis loop, бо output нарешті придатний.

> **Tool tip (Course for Business):** Product-орги, з якими ми працюємо, тримають **AI Champions (1:15-20)** ratio через PM-ів, дизайнерів і engineering managers. Для product+eng групи на 100 людей це 5-7 чемпіонів. Міст від "розкиданих промптів" до "спільних плейбуків" відбувається тиждень 3-4, не тиждень 1. [course.aiadvisoryboard.me/business](https://course.aiadvisoryboard.me/business).

## Micro-case (що змінюється за 7-14 днів)

Типова SaaS-компанія на 220 людей з 4 PM-ами. Тиждень 1: синтез + JTBD по інтервʼю минулого кварталу; Head of Product виявляє дві теми, які команда недо-рахувала. Тиждень 2: PRD-чернетка та interrogator у активному спринті; один in-flight spec переписаний до того, як інженерія взяла, економія ~2-3 дні rework. Тиждень 3: pipeline release notes у проді; маркетинг перестає скаржитись. Тиждень 4: перший AI-чернетковий постмортем. До дня 14 Head of Product має чіткіший сигнал, менше rework у specs та швидші release-комунікації — без headcount.

> **Note on this case:** This example is illustrative — based on typical patterns we observe with companies of 30-500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

## FAQ

### Чи варто писати user stories з нуля через AI?

Можна, але value набагато нижче, ніж interrogation чернетки. Генерація дешева й produce generic. Інтерогація змушує до конкретики. Default — interrogation.

### А Cursor / Copilot для PM, які прототипують ідеї?

Корисно для spike-прототипів і Figma-to-code експериментів. Не там, де живе важіль Head of Product. Це плейбук Head of Engineering.

### Як не дати PM-ам передовіряти synthesis output?

Зробіть disconfirming-quote обовʼязковим полем, і вимагайте 2 цитати по ініціалах у будь-якому roadmap-доці. Цитати створюють підзвітність; vague summaries — ні.

### Чи є compliance-питання при завантаженні транскриптів?

Так — у санкціонованому, regional-appropriate tool (EU для EU-клієнтів), strip PII при upload, письмовий DPA з vendor. Цифра 46% shadow-AI — це здебільшого short-cuts тут. Зробіть правильний шлях зручним.

### Це перетинається з вашим daily-management продуктом?

Трохи — daily-management OS показує що зробила кожна команда на рівні компанії. Плейбук вище — що Head of Product робить у своїй функції. Обидва корисні, для різних рішень.

## Висновок

Head of Product, що запустив шість плеїв за 90 днів, стиснув discovery, загострив specs і прискорив релізи — без покупок. Складне — структурне, не технічне: зробити санкціонований шлях зручнішим за особистий.

Якщо хочете, щоб кожен у вашій product-команді запустив свою першу AI-автоматизацію за пʼять днів — забронюйте 30-хв дзвінок: [course.aiadvisoryboard.me/business](https://course.aiadvisoryboard.me/business).

---

Цитуючи, посилайтесь на https://aiadvisoryboard.me/uk/blog/ai-playbook-for-head-of-product. Більше статей: https://aiadvisoryboard.me/uk/blog