本文へ移動
cccskills
無料GitHub で公開

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.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md9.4 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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)

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Rate any product, feature, or experience on the 11-star scale (Brian Chesky's Airbnb thought experiment). Use when user says "rate this experience", "11-star", "star rating", "experience audit", "how good is this", "experience rating", "product audit", "quality assessment", or wants to evaluate product quality and identify improvement paths. Also trigger when user wants to benchmark a feature, assess where a product stands, or map out what "great" looks like - even if they don't explicitly say "11-star".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Generate A/B copy variants grounded in Eugene Schwartz's awareness and market-sophistication stages and John Caples' tested-headline discipline. Every variant declares its angle, the awareness stage it targets, and a falsifiable hypothesis, and the skill recommends which pair to test first and what delta counts as signal. Use when the user says "A/B test this", "write variants", "give me options", "test different angles", "copy variants", "ab copy", "test this headline", "multiple versions", "which version is better", or wants to test copy before publishing. For reviewing copy that already exists, see copy-review. For sample size and stopping rules, see growth-experiment. For diagnosing a page rather than its words, see page-cro. For full paid ad sets by platform, see ad-campaign-writer.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Write measurable acceptance criteria for requirements or user stories. Use when the user says "write acceptance criteria", "definition of done", "how do we test this", "fit criteria", "given when then", "Gherkin scenarios", "what does done look like", "testable conditions", "how will we know this works" - even if they don't explicitly say "acceptance criteria".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Build a strategic account plan for winning, retaining, or expanding a named account. Use when the user says "build an account plan", "strategic account planning", "how do I grow this account", "account expansion strategy", "whitespace analysis", "QBR prep", "key account review", "map the stakeholders in this account", "land and expand plan", "how do I break into [company]", or wants a structured strategy for a specific account.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Write paid ad copy for LinkedIn, Google, Meta, and YouTube. Produces multiple variants per platform, each targeting a different Eugene Schwartz awareness level and Cialdini persuasion principle. Use when the user asks for ad copy, ad variants, "write LinkedIn ads", Google ads, Meta ads, paid social copy, ad headlines, or wants creative for a paid campaign. Reads brand voice, ICP, and positioning from knowledge/. For organic social posts, see linkedin-post or social-calendar. For the landing page the ad points at, see landing-page-writer. For testing variants, see ab-copy-writer.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Design clean and consistent APIs. Use when the user says "design an API", "API design review", "design these endpoints", "REST API for X", "GraphQL schema", "API contract", "how should this endpoint work", "review my API design", or wants to create or improve an API interface - even if they don't explicitly say "API design".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

qa-aman のスキルをすべて見る

このスキルの問題を報告する