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

Найбільша помилка SMB-засновників у board prep — сприймати pre-read і meeting deck як один документ із різними розширеннями. Це різні роботи. Різний контент. 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.