# Findings Presentation

> Structure a consulting findings presentation using the Pyramid Principle storyline. Use when a consultant says "help me structure my presentation", "I have findings and need to present them", "how do I structure the deck", "build me the storyline", "help me tell the story of the findings", "I have data but no narrative", "client presentation is next week", "how do I present recommendations to the steering committee", or "the deck needs a through-line". Also trigger when someone has completed analysis and needs to communicate findings and recommendations to senior client stakeholders in a structured, persuasive format.

- Skill: `qa-aman/findings-presentation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add qa-aman/findings-presentation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qa-aman/findings-presentation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: qa-aman (https://skillmd.com/u/qa-aman)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/qa-aman/findings-presentation

---


## Overview

Based on **"The Pyramid Principle"** by Barbara Minto. A findings presentation is not a documentary of your analytical process - it is a structured argument. The storyline follows situation-complication-resolution, the answer leads, and every slide makes a single assertion that the evidence on that slide proves. The audience should be able to read only the slide titles in sequence and understand the full argument.

The key test: if you remove all charts and bullets and read the slide titles in order, do they tell a coherent, complete story? If yes, the deck has a good storyline. If not, the structure needs work before the content does.

## Workflow

### Step 1: Define the Audience and the Ask

Before building a single slide, answer:
1. Who is in the room? (Titles, decision authority, what they care about)
2. What is the decision or action you want from this meeting?
3. What do they already know and believe?
4. What might they resist?

The ask governs the whole deck. A presentation where you want the client to approve a recommendation is structured differently from one where you want to align them on the problem diagnosis.

### Step 2: Build the Storyline (Titles Only)

Write slide titles for the entire deck before creating any content. Each title must be an assertion (a sentence with a point of view), not a label.

- Label (weak): "Revenue Analysis"
- Assertion (strong): "Revenue has declined 18% YoY, driven entirely by mid-market churn"

A 15-slide presentation should have 15 assertions that, read in sequence, form a complete argument from problem to recommendation.

Storyline structure:
```
1-2. [Situation] - Business context that sets the stage
1-2. [Complication] - What has changed or is at risk
1.   [Main message] - Your headline finding or recommendation
2-4. [Evidence block 1] - Supports main message
2-4. [Evidence block 2] - Supports main message
2-4. [Evidence block 3] - If needed
1-2. [Implications] - What this means for the client
1-3. [Recommendations] - Specific actions
1.   [Next steps] - Who does what by when
```

### Step 3: Write the Opening (Situation-Complication-Resolution)

The first 3-4 slides establish context, create tension, and state the main message.

**Slide 1 - Situation**: Non-controversial context the audience already knows and agrees with. Sets the shared starting point.

Title example: "[Your client] serves [X] customers across [Y] markets with [Z] in revenue"

**Slide 2 - Complication**: The change or risk that makes the rest of the deck necessary. Contains the key data point that drives urgency.

Title example: "Despite market growth, [your client]'s revenue has declined 18% - a gap of $X vs. target"

**Slide 3 - Main Message**: The answer. Your core finding or recommendation, stated directly. This is the single most important slide in the deck.

Title example: "Three fixable failures in the mid-market sales process explain the full revenue gap"

Everything after Slide 3 proves the main message.

### Step 4: Structure Evidence Blocks (MECE)

Group your supporting findings into 2-4 MECE clusters. Each cluster becomes an evidence block with its own assertion slide (governing thought) followed by supporting evidence slides.

Evidence block structure:
```
Block assertion: "[Main claim of this block]"
  - Evidence slide 1: "[Specific finding that supports the block assertion]"
  - Evidence slide 2: "[Specific finding that supports the block assertion]"
  - Evidence slide 3: [If needed]
```

MECE test for evidence blocks:
- Each piece of evidence supports exactly one block assertion (no overlaps)
- The blocks together fully prove the main message (no gaps)

Example:
```
Main message: Three fixable failures explain the revenue gap

Block 1: "Outbound prospecting volume has dropped 40% since [date]"
  - Evidence: Prospecting activity data by quarter
  - Evidence: Sales rep time allocation shifted to account management

Block 2: "Mid-market qualification criteria changed but sales training did not"
  - Evidence: Pipeline data showing low-probability deals entering funnel
  - Evidence: Survey: 70% of reps cannot articulate new ICP criteria

Block 3: "Close rates dropped due to proposals that do not address buyer economics"
  - Evidence: Win/loss interview summary
  - Evidence: Proposal quality scoring across won vs. lost deals
```

### Step 5: Design Individual Slides

Each slide: one assertion, one supporting visual or table, minimal text.

**Slide anatomy:**
- Title: The assertion (the so-what of the slide)
- Body: One chart, table, or structured list that proves the title
- Callout/annotation: The key data point highlighted directly on the visual
- Source: Data source in small type at bottom

**One-slide tests:**
1. If someone reads only the title, do they get the main point?
2. Does the visual prove the title - or does it show something adjacent?
3. Is there anything on this slide that does not directly support the title? (Remove it)

Common slide types:
- **Diagnostic slide**: shows the problem or its root cause (bar chart, waterfall, scatter)
- **Benchmark slide**: compares client to peers or best practice (bar chart with reference line)
- **Process/framework slide**: shows a structure or flow (table, decision tree)
- **Implication slide**: translates a finding into a business consequence (narrative + one data point)
- **Recommendation slide**: states the action with supporting rationale (structured list or 2x2)

### Step 6: Build the Recommendations Section

Each recommendation:
1. Is directly anchored to a finding (make the linkage explicit)
2. Is specific (what to do, not "consider" or "explore")
3. Has an owner, timeline, and expected outcome

Template per recommendation:
```
Recommendation [X]: [Title as a clear directive]
Because: [Finding that drives this recommendation - 1 sentence]
Action: [Specific action - verb + object + timeframe]
Owner: [Role]
Expected outcome: [Measurable result]
Effort: [High / Medium / Low]
Impact: [High / Medium / Low]
```

### Step 7: Close with Next Steps

The final slide is a single clear action table. One thing to leave with: who is doing what by when.

Template:
```
| Action                           | Owner               | By When  |
|----------------------------------|---------------------|----------|
| [Specific action 1]              | [Role]              | [Date]   |
| [Specific action 2]              | [Role]              | [Date]   |
| [Decision: approve/reject X]     | [Executive sponsor] | [Date]   |
```

No more than 5 items. If there are 10 next steps, the presentation did not achieve alignment on priorities.

## Anti-Patterns

**1. Slide titles as labels**
Bad: "Customer Analysis", "Revenue Trends", "Recommendations"
Good: "Mid-market customers churn at 3x the rate of enterprise", "Revenue declined 18% driven by mid-market", "Fixing qualification criteria would recover $X in 12 months"
Label titles make the audience work to find the point. Assertion titles state the point and use the visual as proof.

**2. Story that follows the analytical process**
Bad: "First we looked at revenue, then we looked at cost, then we interviewed customers..."
Good: Situation - Complication - Main message - Proof - Recommendations
The audience does not care how you found the answer. They care what the answer is.

**3. Burying the main message**
Bad: 8 slides of findings before a synthesis slide at slide 9 that says "therefore..."
Good: Main message stated at slide 3. Everything after proves it.
Clients want to evaluate your conclusion as they consume the evidence.

**4. Multiple assertions on one slide**
Bad: A slide titled "Revenue is declining and customers are churning and our NPS is low"
Good: One assertion per slide. Three things happening means three slides, or one synthesis slide with a single overarching point.

**5. Evidence that does not prove the title**
Bad: Title says "Mid-market churn is the primary driver" but the chart shows overall revenue by product line.
Good: Title and visual are in a direct proof relationship.
Mismatched titles and visuals signal that the deck was assembled, not argued.

## Quality Checklist

- [ ] Audience and ask defined before any slides were built
- [ ] All slide titles are assertions (sentences with a point of view), not labels
- [ ] Titles read in sequence tell a complete, coherent story (storyline test)
- [ ] Opening follows Situation - Complication - Main Message
- [ ] Main message stated by slide 3-4 (not buried at the end)
- [ ] Evidence blocks are MECE - no overlaps, no gaps
- [ ] Each evidence slide title is proven by the visual on that slide
- [ ] Each slide makes one assertion, supported by one visual
- [ ] Recommendations are specific directives, not "explore" or "consider"
- [ ] Recommendations are linked to specific findings
- [ ] Next steps table has owner, action, and date for each item (max 5)
- [ ] Deck is readable title-only (storyline test passes)