# Board pre-read vs meeting deck: what AI helps with on each

> The pre-read and the deck are two different documents doing two different jobs. AI helps with both, but in opposite directions — pre-read needs density, deck needs focus. How to use each well.

- Author: Yaroslav Maxymovych (Founder & CEO, AI Advisory Board)
- Published: 2026-06-12
- Updated: 2026-10-30
- Source: https://aiadvisoryboard.me/blog/board-pre-read-versus-meeting-deck

The single biggest mistake I see SMB founders make in board prep is treating the pre-read and the meeting deck as the same document with different file extensions. They do different jobs. They need different content. They need AI used differently — and most founders use it the same way on both, which is why both end up mediocre.

## TL;DR

- The pre-read is for reading; the deck is for talking. Pre-read needs density and detail so board members come prepared. Deck needs focus and decisions so the meeting moves.
- AI helps with both — but oppositely. On the pre-read, AI's job is to assemble dense, sourced detail. On the deck, AI's job is to compress and cut.
- Most founders generate the deck from the pre-read by deleting slides. The right move is to start the deck from the meeting's decision agenda — and let AI compress, not duplicate.

## Why are these two different documents?

Because they serve two different cognitive tasks. The pre-read is consumed alone, at the board member's pace, the night before. The deck is consumed live, with the founder talking over it, in 90 minutes.

> **Definition:** Board pre-read — a written document sent to board members 48-72 hours before the meeting, dense with data and context, designed for solo study.

> **Definition:** Board meeting deck — a visual presentation used during the live board meeting, designed to anchor discussion and drive decisions, not to convey detail.

The board member who reads the pre-read carefully should arrive at the meeting with questions about specific numbers. The deck should not re-state those numbers — it should drive the conversation forward to decisions.

When you merge them, both fail. The pre-read becomes too light to actually prepare anyone. The deck becomes too dense to discuss.

## What goes in each — and what doesn't?

### Pre-read content

- Full financial summary with cohort drill-downs
- Operating metrics across every function, with trends
- Full customer health table or sample
- Detailed competitive update
- Status of every previous-quarter commitment
- Risk register with detail
- Full HR / hiring update
- Strategic narrative — the founder's view, 1-2 pages

### Pre-read explicitly NOT in deck

- Detail tables (cohorts, customer lists)
- Function-by-function operating updates
- Risk register granularity
- Hiring status by role
- Past commitment status (referenced, not displayed)

### Deck content

- 1 slide: agenda and decisions required
- 1 slide: headline metrics, current vs target
- 2-3 slides: the strategic question or bet for this quarter
- 1 slide per decision item (4-6 max)
- 1 slide: asks of the board
- 1 slide: forward-looking risks (3-5)

### Deck explicitly NOT in pre-read

- Decision-framing slides (these are unique to the meeting)
- Founder's "what I want from this meeting" slide
- Time-boxed agenda

The pre-read is reference. The deck is a working session.

## How does AI help on the pre-read?

The pre-read's job is dense, sourced detail. AI's role is assembly and consistency.

- Pull and format all operating metrics from raw exports
- Generate the function-by-function update from each function head's input
- Compile the past-commitment status table from last quarter's pre-read
- Assemble the cohort drill-down from finance exports
- Cross-check every number against finance system of record

The founder writes the strategic narrative (1-2 pages). Everything else AI assembles, founder reviews.

> **Tool tip (AIAdvisoryBoard.me):** Pre-reads collapse to roughly 60 minutes of founder review time when each function's operating data is already structured. The Plan → Fact → Gap discipline means every function has already declared its plan, recorded its fact, and named its gap by board-prep day — AI just collates. Without that upstream structure, the pre-read takes 6+ hours every quarter because the data is reconstructed from scratch each time. See the 7-day diagnostic at https://aiadvisoryboard.me/?lang=en.

## How does AI help on the deck — differently?

The deck's job is focus. AI's role is compression and cutting.

- Take the pre-read and ask AI: "what are the 3-5 decisions a board member would push for in this meeting given this data?"
- Take the operating updates and ask AI: "what's the one headline number per function that should appear, and which can be omitted?"
- Take the strategic narrative and ask AI to compress it to the 3 sentences that go on a single decision slide
- Generate alternative framings for each decision slide so founder can pick the sharpest

The skill being asked of AI is opposite: not "give me detail" but "tell me what's not earning its slide."

## Copy/paste deck-compression prompt

```
You are reviewing a board pre-read (attached). Your job is to identify
what belongs in the live meeting deck and what does NOT.

The deck is 8-12 slides. The pre-read is 20-40 pages. Most of the
pre-read does NOT belong in the deck — it's been read.

For each candidate deck slide, output:
- Slide title (1 line)
- Why this slide drives a decision or discussion (1 sentence)
- The headline number or insight that goes on it (1-2 lines max)
- What was in the pre-read on this topic that should NOT appear on the
  slide (1-2 lines)

Then propose 4-6 decision items. For each:
- The decision the board is being asked to make
- The 2-3 options being weighed
- The founder's recommendation, in one line

Do NOT include slides for:
- Operating updates that don't require a decision
- Function status that's already in pre-read and not driving a discussion
- Past performance celebration

The slides you propose are candidates. The founder cuts further.
```

The "candidates" framing matters. AI's bias is to be helpful by proposing more; the founder's job is to be ruthless by accepting less.

## What about the strategic narrative — same on both?

No. Different versions, same underlying view.

**On the pre-read:** the founder writes 1-2 pages — the full strategic argument with context, alternatives considered, and reasoning. Board members read this alone the night before.

**On the deck:** the founder compresses the same argument to a 3-sentence claim on a single decision slide. AI helps with compression — propose 5 versions, founder picks the sharpest.

The board members read the long version, then hear the short version with conversation around it. That's the design.

## Good vs bad approaches

**Bad:** Founder writes the pre-read, then exports each page to a slide. Deck is 38 slides. Board glazes over by slide 15.

**Good:** Founder writes the pre-read, then sits with the AI compression prompt and asks "what 8-12 slides drive the meeting?" Most pre-read content stays in the pre-read.

**Bad:** Founder skips the pre-read because "the deck covers it." Board arrives unprepared. Meeting becomes a status update instead of a decision session.

**Good:** Founder writes pre-read 72 hours before. Deck assembled 24 hours before — explicitly for the live discussion only.

**Bad:** Pre-read has shallow operating data because founder ran out of time. Deck is dense to compensate. Both fail.

**Good:** Pre-read assembly is delegated to AI working from clean operating inputs. Founder's time goes to strategic narrative and deck compression — the parts only the founder can do.

## Manager scan (2-minute digest example)

- **Plan:** Pre-read out 72 hours before meeting, deck 24 hours before. Pre-read ~25 pages, deck 10 slides.
- **Fact:** Last meeting's pre-read was 12 pages; deck was 22 slides. Board feedback: "deck was too long, pre-read too thin."
- **Gap:** Founder was generating deck from blank instead of from pre-read; pre-read shortcut meant detail went into deck instead.
- **Plan:** AI assembles pre-read from function inputs; founder writes narrative; AI compresses to deck candidates.
- **Fact:** Function inputs from product and CS arrived day-of; finance was on time.
- **Gap:** Pre-read drafting started late; deck compression skipped. Need function-input deadline 5 days before, not 2.
- **Plan:** 4-6 decision items in deck.
- **Fact:** AI proposed 8 decisions, founder cut to 4. Two of cut items now in pre-read appendix for board awareness.
- **Gap:** Workflow worked — keep this pattern.

## Micro-case (what changes after 7-14 days)

A 110-person services company founder had been getting consistent board feedback that meetings felt unproductive — "we spend an hour catching up on status, fifteen minutes on decisions." Investigation showed the pre-read was thin (the founder didn't have time) and the deck had absorbed all the operating detail. The founder split the work: AI-assembled pre-read pulling from function-head inputs that were already structured, founder-written narrative, then AI compression to a 9-slide deck. First meeting under the new pattern: pre-read was 28 pages, deck was 9 slides, meeting moved through 5 decisions in 75 minutes and left 15 for strategic discussion. The lead investor said it was the most useful board session in a year.

> **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.

> **Tool tip (AIAdvisoryBoard.me):** The reason most pre-reads stay thin is that function-head inputs arrive late, in inconsistent shapes, and the founder reconstructs the operating reality each quarter. Plan → Fact → Gap visibility means every function has been declaring plan, recording fact, and naming gap daily — so pre-read assembly is collation, not reconstruction. The founder's time goes to strategy and compression, the only parts that need them. See https://aiadvisoryboard.me/?lang=en.

## FAQ

**Should the deck be sent to the board with the pre-read or held to the meeting?**
Held to the meeting. The deck is for live use; sending it ahead invites board members to read it instead of the pre-read, defeating the design.

**What if my board says they don't read the pre-read?**
Two possible causes. Either the pre-read isn't worth reading (thin, repetitive, no real insight) — fix the content. Or the deck has redundantly covered everything, so reading it isn't necessary — fix the deck. Usually both.

**Can AI generate the deck directly without a pre-read?**
You can. The result is a deck without an underlying decision-ready record, which means board members can't engage critically. The pre-read is the foundation; skipping it makes the deck weaker, not faster.

**How long should the pre-read actually be?**
20-40 pages for a stage-appropriate SMB. Earlier-stage rounds run lighter (15-25); growth-stage runs heavier (35-50). The right length is "everything needed for a prepared board member to arrive with sharp questions" — no more.

## Conclusion

Pre-read and deck are two documents, two jobs. Pre-read needs density and detail; AI assembles. Deck needs focus and decisions; AI compresses. Treating them as the same document — or generating one from the other by deletion — makes both worse.

Write next quarter's pre-read with AI as assembler. Build the deck from a decisions agenda, with AI as compressor. Send the pre-read 72 hours out. Bring the deck to the room.

If you want a system where each function's plan, fact, and gap is already structured daily — so pre-read assembly is a collation, not a reconstruction — see how the 7-day diagnostic works at https://aiadvisoryboard.me/?lang=en.

---

When citing, link to https://aiadvisoryboard.me/blog/board-pre-read-versus-meeting-deck. More articles: https://aiadvisoryboard.me/blog