# Founder Communication

> How designers communicate with founders, executives, and stakeholders. Framing design decisions in business language.

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

---


# Founder Communication

## The Core Problem

Designers speak in design language. Founders speak in business language. Most design communication fails because designers present solutions without connecting them to outcomes that founders care about.

## What Founders Care About

1. **Revenue impact** — Will this make us more money?
2. **User growth** — Will this bring or retain more users?
3. **Speed** — How fast can we ship this?
4. **Risk** — What could go wrong?
5. **Competitive position** — Does this move us ahead?

Notice: none of these are about color, typography, or spacing. That's the translation work you need to do.

## Framing Design Decisions

### Bad: Design Language
"I chose a larger type scale with more whitespace to create a better visual hierarchy and improve the reading experience."

### Good: Business Language
"The current page has a 23% bounce rate. By improving readability and making the CTA more prominent, similar changes at [comparable company] saw bounce rate drop 15-20%."

### The Formula
**[Design decision]** because **[user behavior it addresses]** which will **[business outcome it drives]**.

## Presenting Design Work to Founders

### Structure (15 min max)
1. **Remind them of the problem** (1 min) — "Last month, 40% of new users dropped off during onboarding."
2. **Show the key decision** (3 min) — Not 50 screens. The 1-2 screens that represent the strategic shift.
3. **Explain the rationale** (3 min) — In business language, not design language.
4. **Show the evidence** (3 min) — User data, competitive analysis, prototype test results.
5. **State what you need** (2 min) — Engineering time, content, approval. Be specific.
6. **Handle questions** (3 min)

### Rules
- Never present more than 3 options. Two is ideal. One is fine if you're confident.
- Never present without a recommendation. "Which do you prefer?" puts the design decision on a non-designer.
- Always have a next step ready.
- If they disagree, ask "What would change your mind?" instead of defending.

## When to Push Back

Push back when:
- A request contradicts user research
- A request creates technical debt that will cost more later
- A request damages brand consistency
- "Can we just..." will take 3x longer than they think

How to push back:
"I hear you. Here's my concern: [specific issue]. What if we [alternative] instead? That gets us [their goal] without [the problem]."

Never: "That's not how design works."