# Board pre-read vs meeting deck: чим AI допомагає на кожному

> Pre-read і дек — два документи з різними завданнями. AI допомагає обом, але в протилежних напрямках: pre-read — щільність, дек — фокус. Як правильно використати AI на кожному.

- Автор: Ярослав Максимович (Founder & CEO, AI Advisory Board)
- Опубліковано: 2026-06-12
- Оновлено: 2026-10-26
- Джерело: https://aiadvisoryboard.me/uk/blog/board-pre-read-versus-meeting-deck

Найбільша помилка SMB-засновників у board prep — сприймати pre-read і meeting deck як один документ із різними розширеннями. Це різні роботи. Різний контент. AI потрібен по-різному — а більшість засновників використовує його однаково, тому обидва виходять посередніми.

## TL;DR

- Pre-read — для читання; дек — для розмови. Pre-read потребує щільності й деталей, щоб board члени прийшли підготовленими. Дек — фокусу й рішень, щоб мітинг рухався.
- AI допомагає обом — але навпаки. На pre-read AI збирає щільний source-traced детал. На деку AI стискає й вирізає.
- Більшість засновників генерує дек із pre-read шляхом видалення слайдів. Правильний хід — стартувати дек з agenda рішень, а AI стискає, не дублює.

## Чому це два різні документи?

Бо вони служать двом різним когнітивним задачам. Pre-read читається наодинці, у темпі члена board, увечері напередодні. Дек поглинається наживо, із засновником, що говорить поверх, за 90 хвилин.

> **Definition:** Board pre-read — письмовий документ за 48-72 годин до мітингу, щільний даними, для соло-вивчення.

> **Definition:** Board meeting deck — візуальна презентація для живого мітингу, що закріплює дискусію й веде рішення, не передає деталь.

Member board, що уважно прочитав pre-read, приходить із питаннями про конкретні цифри. Дек не має повторювати — він рухає розмову до рішень.

Коли ви їх зливаєте, обидва провалюються. Pre-read стає занадто легким, щоб когось підготувати. Дек — занадто щільним, щоб обговорити.

## Що в кожному — і чого ні?

### Контент pre-read

- Повне фін-сумарі з cohort drill-down
- Operating metrics по функціях із трендами
- Customer health table
- Detailed competitive update
- Status кожного minulого quarter commitment
- Risk register
- Повний HR/hiring update
- Стратегічний наратив — погляд засновника, 1-2 сторінки

### НЕ в деку

- Detail tables (cohorts, customer lists)
- Function-by-function operating updates
- Risk register granularity
- Hiring status по ролях
- Past commitment status (reference only)

### Контент деку

- 1 слайд: agenda і потрібні рішення
- 1 слайд: headline metrics, current vs target
- 2-3 слайди: стратегічне питання чи ставка кварталу
- 1 слайд на decision item (4-6 макс)
- 1 слайд: asks of the board
- 1 слайд: forward-looking risks (3-5)

### НЕ в pre-read

- Decision-framing слайди (унікальні мітингу)
- Founder's «what I want from this meeting» слайд
- Time-boxed agenda

Pre-read — reference. Дек — робоча сесія.

## Як AI допомагає на pre-read?

Pre-read — щільні sourced деталі. AI — збірка і консистентність.

- Витягнути й відформатувати всі operating metrics з raw-експортів
- Згенерувати function-by-function update з input-у голів функцій
- Скласти past-commitment status table з минулого pre-read
- Зібрати cohort drill-down з finance-експортів
- Крос-чекнути кожну цифру з finance system of record

Засновник пише стратегічний наратив (1-2 ст). Решту збирає AI, founder ревʼює.

> **Tool tip (AIAdvisoryBoard.me):** Pre-read стискається до ~60 хв ревʼю засновника, коли operating data кожної функції вже структурована. Дисципліна Plan → Fact → Gap означає, що кожна функція вже задекларувала plan, записала fact, назвала gap до board-prep day — AI лише колятить. Без цього pre-read щокварталу — 6+ годин, бо дані реконструюються з нуля. https://aiadvisoryboard.me/?lang=en.

## Як AI допомагає на деку — інакше?

Робота деку — фокус. AI — стиснення і вирізання.

- Pre-read → AI: «які 3-5 рішень board штовхне в цьому мітингу за цими даними?»
- Operating updates → AI: «яка одна headline цифра на функцію має зʼявитися, що пропустити?»
- Стратегічний наратив → стиснути до 3 речень на decision slide
- Альтернативні формулювання на кожен decision slide, founder обирає найгостріше

Скіл, що просимо в AI, протилежний: не «дай деталь», а «скажи, що не заробляє свого слайду».

## Промпт стиснення деку

```
Ти ревʼює board pre-read (доданий). Робота: визначити, що належить
до live meeting deck, а що НІ.

Дек — 8-12 слайдів. Pre-read — 20-40 сторінок. Більшість pre-read
НЕ належить деку — воно прочитане.

На кожен кандидат-слайд:
- Заголовок (1 рядок)
- Чому цей слайд штовхає рішення/дискусію (1 речення)
- Headline цифра/insight (1-2 рядки макс)
- Що було в pre-read з цієї теми, що НЕ має зʼявитися на слайді
  (1-2 рядки)

Тоді запропонуй 4-6 decision items. На кожен:
- Рішення, яке board просять прийняти
- 2-3 опції, що зважуються
- Рекомендація засновника, 1 рядок

НЕ пропонуй слайди для:
- Operating updates, що не вимагають рішення
- Function status, що в pre-read і не drive дискусію
- Святкування past performance

Слайди — кандидати. Засновник ріже далі.
```

«Кандидати» важливі. AI bias — бути корисним пропонуючи більше; робота засновника — бути нещадним приймаючи менше.

## А стратегічний наратив — однаковий на обох?

Ні. Різні версії, той же погляд.

**На pre-read:** засновник пише 1-2 ст — повний аргумент із контекстом, альтернативами, обґрунтуванням. Board члени читають це наодинці.

**На деку:** засновник стискає той самий аргумент до претензії з 3 речень на одному decision slide. AI допомагає стиснути — пропонує 5 версій, засновник обирає найгострішу.

Board читає довгу версію, тоді чує коротку з розмовою навколо. Це й є дизайн.

## Хороші vs погані підходи

**Погано:** Засновник пише pre-read, потім експортує кожну сторінку у слайд. Дек на 38 слайдів. Board глянсує на 15-му.

**Добре:** Засновник пише pre-read, сідає з компресійним промптом і питає «які 8-12 слайдів drive мітинг?» Більшість pre-read лишається в pre-read.

**Погано:** Засновник пропускає pre-read бо «дек покриває». Board приходить непідготовлений. Мітинг стає status update замість сесії рішень.

**Добре:** Pre-read за 72 години. Дек зібраний за 24 — явно лише для live-дискусії.

**Погано:** Pre-read поверхневі operating data, бо засновник забракло часу. Дек щільний для компенсації. Обидва провалюються.

**Добре:** Збірка pre-read делегована AI з чистих operating inputs. Час засновника — на наратив і стиснення деку, що тільки він може.

## Manager scan (2-хвилинний дайджест)

- **Plan:** Pre-read за 72 години, дек за 24. Pre-read ~25 ст, дек 10 слайдів.
- **Fact:** Минулий pre-read — 12 ст; дек — 22 слайди. Фідбек board: «дек задовгий, pre-read замалий».
- **Gap:** Засновник генерував дек з нуля замість з pre-read; ярлик з pre-read означав, що деталь пішла в дек.
- **Plan:** AI збирає pre-read з function inputs; засновник пише наратив; AI стискає до кандидатів деку.
- **Fact:** Inputs з product і CS прийшли day-of; finance — вчасно.
- **Gap:** Драфтинг pre-read стартував пізно; компресія деку пропущена. Дедлайн function input — 5 днів, не 2.
- **Plan:** 4-6 decision items у деку.
- **Fact:** AI запропонував 8, засновник скоротив до 4. 2 cut items тепер у pre-read appendix для awareness.
- **Gap:** Workflow спрацював — патерн зберігати.

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

Засновник 110-людної сервісної компанії регулярно чув від board, що мітинги непродуктивні — «годину наздоганяємо status, 15 хв на рішення». Розслідування показало: pre-read тонкий (часу немає), дек поглинув усю operating-деталь. Засновник розділив роботу: AI-зібраний pre-read із function-head inputs (вже структурованих), founder-наратив, потім AI-компресія до 9-слайдового деку. Перший мітинг за новим патерном: pre-read 28 ст, дек 9 слайдів, мітинг пройшов 5 рішень за 75 хв і залишив 15 на стратегію. Lead-інвестор сказав, що це найкорисніша board-сесія за рік.

> **Note on this case:** Цей приклад ілюстративний — типові патерни 30-500 людей, не названий клієнт. Цифри — округлені діапазони.

> **Tool tip (AIAdvisoryBoard.me):** Більшість pre-reads лишаються тонкими, бо function-head inputs прибувають пізно, у різних формах, і засновник реконструює operating-реальність щокварталу. Plan → Fact → Gap видимість означає, що кожна функція задекларувала plan, записала fact, назвала gap щодня — pre-read assembly стає колятацією, не реконструкцією. Час засновника — на стратегію і компресію, що лише його. https://aiadvisoryboard.me/?lang=en.

## FAQ

**Слати дек разом із pre-read чи тримати до мітингу?**
Тримати до мітингу. Дек для live-use; вислати наперед = board читає його замість pre-read, ламає дизайн.

**Що, як board каже «pre-read не читаємо»?**
Дві причини. Або pre-read не вартий читання (тонкий, повторний, без insight) — фіксіть контент. Або дек дублює все, читання не потрібне — фіксіть дек. Зазвичай обидва.

**AI може згенерувати дек прямо без pre-read?**
Може. Результат — дек без базового decision-ready запису, board не зможе залучитись критично. Pre-read — фундамент; пропуск робить дек слабшим, не швидшим.

**Якої довжини pre-read?**
20-40 ст для stage-appropriate SMB. Раніша стадія — 15-25; growth — 35-50. Правильна довжина — «усе для підготовленого board члена з гострими питаннями» — не більше.

## Висновок

Pre-read і дек — два документи, дві роботи. Pre-read — щільність і деталь; AI збирає. Дек — фокус і рішення; AI стискає. Сприймати їх однаково — або генерувати один з іншого видаленням — робить обидва гіршими.

Напишіть наступний pre-read з AI-збиральником. Збудуйте дек з decisions agenda, з AI-компресором. Pre-read за 72 години. Дек у кімнаті.

Якщо хочете систему, де plan, fact, gap кожної функції вже структуровані щодня — щоб pre-read assembly була колятацією, не реконструкцією — подивіться 7-денну діагностику: https://aiadvisoryboard.me/?lang=en.

---

Цитуючи, посилайтесь на https://aiadvisoryboard.me/uk/blog/board-pre-read-versus-meeting-deck. Більше статей: https://aiadvisoryboard.me/uk/blog