Executive Writing

Purpose

Produce an executive-ready document — strategy one-pager, board memo, or decision brief — that a VP, C-suite exec, or board member can read and act on without a guided walkthrough. The output encodes Minto Pyramid structure, role-calibrated framing, decision architecture, and zero-jargon compression into a document that a PM cannot produce at this quality unaided.

When to Use / When NOT to Use

Use this skill when:

• Writing a strategy one-pager for executive alignment on a direction
• Preparing a board or exec review memo to be read asynchronously before a meeting
• Drafting a decision brief that must produce a decision in a meeting
• Framing an investment memo, product strategy, or resource allocation request for C-suite approval
• Translating an existing analysis (competitive war map, metric design, spec) into exec-readable format
• Any situation where the reader is a VP+ and the document must produce action, not just comprehension

Do NOT use this skill when:

• You need the analysis itself (use Competitive Market Analysis, Metric Design, or Problem Framing first — then run this skill to package the output)
• The audience is your engineering team or direct reports (write a spec or PRD instead)
• You need a presentation deck (this produces written documents, not slides — though the structure translates)
• The "executive" is actually a working-level PM who wants detail (give them the full analysis)
• You need a project status update (use a dashboard or status template, not a strategic document)

Anti-inputs (what this skill does NOT handle):

• Generating the underlying analysis or evidence (this skill packages existing insight, it does not create it)
• Slide deck design or visual presentation (document structure only)
• Meeting facilitation or talking points (the document stands alone — if it needs a presenter, it failed)
• Organizational communication (all-hands, change management, team announcements)

Context Gate (Step -1)

Before writing anything, verify that an executive document is the right artifact. Answer these four questions:

If all four pass: Proceed to Step 0. If any fail: Address the gap before writing. A document sent to the wrong person, at the wrong time, without a recommendation, is worse than no document.

Reader Navigation

How to Read This Skill

Notation Key

Format Rules (Read First)

These rules govern every output produced by this codex. They are non-negotiable quality enforcement mechanisms.

1. Answer first, evidence second. The recommendation or key message appears in the first paragraph, not the last. An executive who reads only the first 10 seconds gets the answer. Evidence follows to support, not to build suspense. Burying the lead is the most common executive writing failure.

2. Take positions. Never hedge with weasel words. "Likely," "may," "could," and "seems" are banned from recommendations. Flag uncertainty with explicit confidence levels: H (>70% confident), M (40-70%), L (<40%). Example: "We should invest $2M in enterprise security features (H)" not "We may want to consider increasing security investment."

3. Every document ends with an explicit Ask. No exceptions. If the document doesn't ask the reader to decide, align, or provide input, it is an information dump (FM-1). The Ask is specific, time-bound, and actionable.

4. Zero-jargon in the executive-facing body. Framework names, acronyms, and technical terms get plain-language translations on first use. Maximum 5 acronyms per document. The "grandmother test": could a smart non-technical person follow the argument?

5. Evidence compressed to the right level. Headlines get one stat + one implication. Body gets 2-3 supporting data points with source and confidence. Full methodology goes in the appendix. Never put appendix-level evidence in the body — it signals "I don't know what matters" (FM-9).

6. Options are genuinely different. When presenting options, each must differ on at least one structural dimension (cost, risk, timeline, scope). If two options are variations of the same thing, merge them. Always 2-4 options. One option = mandate. Five+ options = indecision.

7. Risks are real or omitted. "Risk: adoption may be slow. Mitigation: we'll monitor and adjust" says nothing (FM-8). State the specific scenario, its probability, its impact, and the concrete mitigation. If you can't do this, the risk isn't understood well enough to include.

8. Framework references get one-line explanations. First mention of any framework or model includes a plain-language description of why it matters for this specific decision. "Using the Minto Pyramid structure (answer first, then supporting logic — because this exec reads 40+ documents a week and skips anything that doesn't lead with the point)."

9. The document must be navigable by someone who didn't write it. A colleague picking up this document cold must be able to extract the recommendation, the options, and the ask without reading front to back. Headers are conclusions, not labels. Bold the mechanism, not the entity.

Output Template (Mandatory Document Skeleton)

Three templates — one per document type. Step 0 selects which to use. Copy the selected skeleton and fill it in.

Template A: Strategy One-Pager

# [Title — Conclusion as Header, Not Topic]

> **Date:** [YYYY-MM-DD] | **Author:** [Name] | **For:** [Audience role + name] | **Ask type:** [Decision / Alignment / Input]

---

## Situation (2-3 sentences)

[What's true today that everyone agrees on. Establish common ground. No new information — just shared reality.]

## Complication (2-3 sentences)

[What changed, what broke, or what opportunity emerged. This is the tension that demands action.]

## Strategic Options

### Option 1: [Name — verb phrase, not noun]
[2-3 sentences. What we'd do, what it costs, what it achieves.]
- **Upside:** [Specific benefit with magnitude]
- **Risk:** [Specific risk with probability and impact]
- **Timeline:** [When we'd see results]

### Option 2: [Name]
[Same structure]

### Option 3: [Name] *(if applicable)*
[Same structure]

**Recommendation:** [State the recommended option clearly. Include confidence level (H/M/L) and the key assumption driving it.]

## Key Risks

| Risk | Probability | Impact | Mitigation |
|------|:-----------:|:------:|------------|
| [Specific scenario] | H/M/L | [Quantified if possible] | [Concrete action] |

## The Ask

[What you need from the reader. By when. What happens if delayed.]

---

*Appendix available on request: [list what's available — full analysis, data tables, sensitivity analysis]*

Template B: Board / Exec Review Memo

# [Title — Strategic Conclusion as Header]

> **Date:** [YYYY-MM-DD] | **Author:** [Name] | **For:** [Board / Exec Team / specific role] | **Read time:** [X min] | **Ask type:** [Decision / Alignment / Input]

---

## TL;DR (3 bullets max)

- [Bullet 1: The situation in one sentence]
- [Bullet 2: The recommendation in one sentence]
- [Bullet 3: The ask in one sentence]

---

## Situation

[2-3 paragraphs. What's true, what the market looks like, where we are. Only include context the reader needs to understand the complication. Not a comprehensive background — just enough to ground what follows.]

## Complication

[1-2 paragraphs. What changed. What's at stake. Why this requires executive attention now, not next quarter.]

## Resolution: [State the Recommendation]

[2-3 paragraphs. The recommended course of action. Why this option over others. What it costs, what it achieves, and by when.]

**Confidence:** [H/M/L] — assumes [key assumption]

## Evidence

### [Evidence Theme 1 — Insight as Header]

[2-3 data points with source and evidence tier. One implication per paragraph.]

### [Evidence Theme 2]

[Same structure]

### [Evidence Theme 3] *(if needed)*

[Same structure]

## Options Considered

| Option | Description | Pros | Cons | Cost | Risk |
|--------|-------------|------|------|:----:|:----:|
| **[Recommended]** | [2 sentences] | [Key pro] | [Key con] | [$$] | H/M/L |
| [Alternative 1] | [2 sentences] | [Key pro] | [Key con] | [$$] | H/M/L |
| [Alternative 2] | [2 sentences] | [Key pro] | [Key con] | [$$] | H/M/L |

## Risks

| Risk | Probability | Impact | Mitigation | Owner |
|------|:-----------:|:------:|------------|-------|
| [Scenario 1] | H/M/L | [$$$ or strategic] | [Concrete action] | [Name/team] |
| [Scenario 2] | H/M/L | [$$$ or strategic] | [Concrete action] | [Name/team] |

## Assumption Registry

| # | Assumption | Confidence | Evidence | What Would Invalidate |
|---|-----------|:----------:|---------|----------------------|
| 1 | [Load-bearing assumption] | H/M/L | [Source (TX)] | [Observable signal] |
| 2 | | | | |
| 3 | | | | |

## The Ask

[What you need. By when. What happens if delayed. What the next step is if approved.]

---

## Appendix *(separate page)*

[Full data tables, methodology, sensitivity analysis, detailed competitor data, source list with evidence tiers. Executives read this only if challenged or curious.]

## Adversarial Self-Critique

**Weakness 1: [Title]**
[What assumption is being made? What evidence would disprove it? Scenario where this recommendation is wrong.]

**Weakness 2: [Title]**
[Same depth]

**Weakness 3: [Title]**
[Same depth]

## Revision Triggers

| Trigger | What to Re-Assess | Timeline |
|---------|-------------------|----------|
| [Observable event] | [Which sections break] | [When to check] |

Template C: Decision Brief

# Decision: [State the Decision in One Sentence]

> **Date:** [YYYY-MM-DD] | **Decision owner:** [Name/role] | **Meeting:** [Date, duration] | **Deadline:** [When the decision must be made]

---

## Decision Statement

[One paragraph. What must be decided. Why now. What happens if we don't decide.]

## Context (4-5 sentences max)

[Only what's needed to evaluate the options. Not a comprehensive background. If the reader needs more, link to the appendix.]

## Options

### Option A: [Name — verb phrase]

[2-3 sentences. What we'd do.]

| Dimension | Assessment |
|-----------|-----------|
| **Cost** | [$$, headcount, opportunity cost] |
| **Timeline** | [When we'd see results] |
| **Risk** | [H/M/L — specific scenario] |
| **Reversibility** | [Easy to reverse / Hard to reverse / One-way door] |
| **Key tradeoff** | [What we give up by choosing this] |

### Option B: [Name]

[Same structure]

### Option C: [Name] *(if applicable)*

[Same structure]

## Recommendation

**[State the recommended option.]** Confidence: [H/M/L].

**Why this option:** [2-3 sentences — the decisive factor]
**Key assumption:** [The single assumption that, if wrong, changes the recommendation]
**What's reversible:** [What we can undo if wrong]
**What's not:** [What we can't undo — the irreversible commitment]

## What We Need from This Meeting

- [ ] **Decision:** [Approve Option X / Choose between A and B / Provide direction on Z]
- [ ] **By:** [Date]
- [ ] **If not decided:** [Consequence — delay cost, missed window, blocked dependency]

---

*Supporting analysis: [link or "available on request"]*

Rules for using these templates:

1. Do not skip sections. If a section isn't applicable, write "Not applicable — [reason]" and move on.
2. Headers are conclusions, not labels. Replace generic headers (e.g., "Market Analysis") with insight headers (e.g., "We're Losing Enterprise Deals on Security, Not Features") after completing the section.
3. The TL;DR / Executive Summary is written last but appears first. Do not write it until all sections are complete.
4. Bold the mechanism, not the entity. "Google's investment is $4-6B annually in TPUs" not "Google is investing in TPUs."
5. Every table cell with a risk rating must include a specific scenario, not just H/M/L.

Domain Frameworks

This section IS the knowledge weapon. Each framework is encoded with its decision tables, scoring rubrics, and application methodology — not merely referenced. A PM using this skill produces executive documents that encode these frameworks; without them, the output degrades to generic summaries.

Framework 1: Format Routing (Step 0)

Before writing a word of content, select the document format. Wrong format = wrong output, regardless of content quality.

Routing Table:

Decision table — format selection:

Scoring rubric — did you pick the right format?

Framework 2: Minto Pyramid / SCR Structure

Barbara Minto's Pyramid Principle is the backbone of executive communication. The structure: answer first, then grouped supporting arguments, then evidence. Executives read top-down and stop when convinced. Structure accordingly.

The SCR Framework (Situation-Complication-Resolution):

Decision table — when to use SCR vs. other structures:

The Pyramid Structure (below the SCR):

                    RESOLUTION (answer)
                   /         |         \
          Argument 1    Argument 2    Argument 3
          /    |   \      /  |  \       /  |  \
       E1.1 E1.2 E1.3  E2.1 E2.2    E3.1 E3.2

Rules for the pyramid:

• MECE at every level. Arguments under the resolution are Mutually Exclusive, Collectively Exhaustive. No overlap. No gaps.
• Each argument is one idea. If an argument contains "and," it's two arguments.
• Evidence supports its argument, not the resolution directly. Don't jump from evidence to conclusion without the intermediate argument.
• Maximum 3-4 arguments per level. More than 4 signals the argument isn't structured.

Scoring rubric — SCR quality:

Framework 3: Audience Calibration by Executive Role

The same information must be framed differently depending on who reads it. A product investment framed for a CEO emphasizes strategic fit. The same investment framed for a CFO emphasizes unit economics. Sending a CEO-framed document to a CFO is FM-6 (Single-Audience Document).

Role calibration matrix:

Example — Same investment, four frames:

Multi-audience calibration (when the document goes to several roles):

• Lead with the decision-maker's frame
• Include a "perspectives" section with 2-3 sentence frames for each stakeholder
• Put role-specific detail in clearly labeled subsections or the appendix
• The TL;DR must work for ALL readers — which means zero jargon and the decision stated plainly

Scoring rubric — audience calibration:

Framework 4: Decision Architecture

How you structure choices determines how executives process them. Bad option architecture produces bad decisions — not because the analysis is wrong, but because the options aren't structured for decision-making.

Type 1 vs. Type 2 Decisions (Bezos Framework):

Decision table — Type 1 vs. Type 2 routing:

Option Architecture Rules:

Tradeoff Matrix (mandatory for Decision Briefs):

Scoring rubric — decision architecture:

Framework 5: Zero-Jargon Compression

Making complex analysis readable by non-specialists is a skill, not an afterthought. Every executive document passes through this compression layer.

The Compression Protocol (apply to every section):

Jargon Translation Table (common PM-to-exec translations):

Compression by document type:

Scoring rubric — zero-jargon compression:

Framework 6: Ask Framing

The Ask is the most important section of any executive document. Everything else — the analysis, the options, the evidence — exists to support the Ask. A document without a clear Ask is an information dump that wastes executive attention.

Three Ask Types:

Ask Structure (mandatory components):

The Meeting Test: If an exec reads this document and doesn't know what to do next, the Ask failed. Apply this test to every document before sending.

Ask Placement Rules:

Anti-patterns:

Scoring rubric — ask framing:

Framework 7: Evidence Cascade for Executives

Executives consume evidence at different depths depending on their role, the stakes, and their trust in the author. Structure evidence in three levels so each reader gets what they need without wading through what they don't.

Three Evidence Levels:

Example — Same evidence at three levels:

Decision table — which level goes where:

Evidence tier tags (inline):

Use the same tier system as other PM Skills Arsenal skills:

Rule: Level 1 evidence (headline) must be T1-T3. If your strongest evidence for a key claim is T4-T6, flag the claim as [EVIDENCE-LIMITED] and state what T1-T2 evidence would strengthen it.

Scoring rubric — evidence cascade:

Framework 8: Document Quality Gate

A pre-submission checklist for executive documents. Run this before sending. Every check is pass/fail.

The 10-Second Test: Hand the document to someone unfamiliar with the topic. After 10 seconds of reading:

• Can they state the recommendation? If not → SCR structure failed (FM-4: Ask Buried)
• Can they identify the Ask? If not → Ask Framing failed (FM-1: Information Dump)
• Can they identify the audience? If not → Audience Calibration failed (FM-6: Single-Audience)

The One-Page Test: Could you cut this document to one page without losing the argument? If yes, it should probably BE one page. If no, the argument is complex enough to warrant a longer format. This test prevents FM-9 (30-Page Strategy Doc).

Full Quality Gate Checklist:

…(truncated)