reference.md
# Lead — Business Goals (verbatim extract)
## v1.3 vocabulary
- **6-piece signal anatomy** — Design intuition + UX metric + User need + Context + Business goal + Direction. The Business goal piece is what this bucket is responsible for naming.
- **Outcome-oriented signal types** — Need / Use / Prefer / Adopt. Distinct from the Attitudinal / Behavioral / Performance / Perceptual UX-metrics taxonomy used in Measure.
## When to use
- When the user is anchoring design work to executive pressures.
- When picking which of the five business pressures the project serves (Growth, Retention, User Experience, Efficiency, Operations).
- When choosing among the 20 measurable goals (e.g., "Achieve product–market fit," "Lower support costs," "Support strategic launches").
- When stacking the three KPI layers — Design KPIs (task completion, error rate) → Product KPIs (adoption, retention) → Business KPIs (revenue, churn, LTV).
- When running the three-question Quick Test to separate signal from vanity.
**Don't use when** translating into specific function language (use `glare-lead-workflows`), drawing the User Need → KPI ladder (`glare-lead-mapping`), or running the Initiatives → Findings → Decisions → Outcomes loop (`glare-lead-results`).
## Glare | Lead, Business Goals v1.0 (source title still: "Glare | Show, Business Goals v1.0")
Why metrics die in dashboards: they don't connect to goals. A *signal* ties a metric to intent, creating a chain (task success → adoption → growth) that is proof, not just numbers.
The **Three Layers of Goals**:
- **Design KPIs** → Do users succeed in the moment? (task completion, error rates, time on task)
- **Product KPIs** → Do they adopt and return? (feature usage, retention, engagement)
- **Business KPIs** → Does the company benefit? (revenue growth, churn reduction, lifetime value)
**20 measurable goals mapped to 9 business pressures** (verbatim):
Growth
- Prove product fit → Achieve product–market fit
- Attract new customers → Drive revenue growth
- Grow sales → Choose high-impact investments
- Gain market share → Support the bigger picture
Retention
- Keep customers → Build brand loyalty
- Reduce churn → Achieve product–market fit
- Earn loyalty → Build brand loyalty
- Increase spend → Drive revenue growth
User Experience
- Show value fast → Support strategic product launches
- Drive adoption → Achieve product–market fit
- Improve customer satisfaction → Make informed design decisions
- Prove launch success → Support strategic product launches
Efficiency
- Work faster → Improve team efficiency
- Lower support costs → Reduce support costs
- Scale efficiently → Support the bigger picture
- Fund what matters → Choose high-impact investments
Operations
- Align strategy → Support the bigger picture
- Lead with evidence → Make informed design decisions
- Strengthen brand trust → Build brand loyalty
- Prove design impact → Support the bigger picture
**Pitfalls to avoid**: chasing vanity metrics; mistaking correlation for causation; reporting without connecting metrics to outcomes.
**Quick Test** (a metric becomes a *signal* only if all three are yes):
1. Does it prove the design works for users?
2. Does it show adoption or retention at the product level?
3. Does it connect to growth, churn, or revenue at the business level?
## Failure modes
These are common ways this skill goes wrong in practice:
- **Picking a pressure that doesn't actually own the project.** Naming "Growth" because it sounds urgent when the real pressure is Retention or Efficiency. The Quick Test catches this — check whether the project actually moves the named pressure.
- **Skipping straight to Business KPIs.** Tying design to revenue without the Design and Product KPI layers in between leaves the chain unfalsifiable. The three layers exist so cause and effect stay visible.
- **Vanity metrics dressed as business KPIs.** Reporting "engagement up 30%" without checking whether the engagement is on a workflow tied to a business pressure. Engagement on a vanity surface isn't a business KPI.
- **Correlation-as-causation.** "We launched and revenue moved" — without isolating other factors, the correlation is a story, not a goal. Name what would falsify the causal claim before reporting it.
## Related key terms
- **Signal** — a metric tied to intent; only counts as a signal when it answers yes across user / product / business layers.
- **Design KPIs / UX metrics** — completion rate, error rate, comprehension, effort, sentiment, time on task.
- **Product KPIs** — adoption rate, retention, engagement depth, feature usage, DAU/WAU, trial-to-paid conversion.
- **Business KPIs** — revenue growth, churn, LTV, CAC, ROI, cost savings, margin, market share.
- **Nine business pressures** — Growth, Retention, User Experience, Efficiency, Operations (the doc also implies Strategy/Finance/Risk in workflow form).
- **20 measurable goals** — five buckets of four goals (Growth, Retention, UX, Efficiency, Operations) each tying up to a strategic pressure.
- **Vanity metrics** — pageviews/clicks not tied to adoption or retention; explicit anti-pattern.
SKILL.md
---
name: glare-lead-business-goals
description: Use this skill when the user is anchoring design work to executive pressures — the Business Goals bucket of the Lead facet. Triggers — picking which business pressure a project serves (Growth, Retention, User Experience, Efficiency, Operations), choosing among the 20 measurable goals (e.g., "Achieve product–market fit", "Lower support costs", "Support strategic launches"), the three KPI layers (Design KPIs like task completion / error rate; Product KPIs like adoption / retention; Business KPIs like revenue / churn / LTV), the three-question Quick Test to spot signals vs vanity, anti-patterns (vanity metrics, correlation-as-causation, reporting without connecting). Do NOT use for cross-functional translation — use `glare-lead-workflows`. Do NOT use for the User Need → KPI ladder — use `glare-lead-mapping`. Do NOT use for the Initiatives → Findings → Decisions → Outcomes loop — use `glare-lead-results`. For broader Lead, use `glare-lead`.
version: 3.1.0
source_doc_version: v1.0
last_rebuilt: 2026-05-13
---
You are helping the user work through the **Business Goals** bucket of the Glare Lead facet — the upward-facing area of the **Decision Map** that anchors design to the pressures leadership already tracks so design becomes a lever, not decoration.
## Core idea
Business Goals is part of the upward-facing area of the Decision Map (Lead). A metric only matters when it's tied to intent. Business Goals stacks three layers of KPIs (Design → Product → Business) and routes them to one of nine business pressures via 20 named goals, so every signal can be defended as proof of impact rather than a number on a dashboard.
## Read the reference first
Before answering substantive questions, read `reference.md` — it contains the verbatim Three Layers of Goals, the full 20 goals × 9 pressures map, the Quick Test, and the explicit pitfalls to avoid.
## How to apply
1. **Name the layer first.** Ask which of the three layers the user's metric lives in: Design KPI (task completion, error rate, time on task), Product KPI (feature usage, retention, engagement), or Business KPI (revenue growth, churn reduction, LTV). If the user can't classify it, that's the first thing to fix.
2. **Route to one of the 9 business pressures.** The pressures are Growth, Retention, User Experience, Efficiency, Operations (with Strategy / Finance / Risk implied through the workflow lens). Force a single primary pressure — work that "serves all of them" usually serves none.
3. **Pick a measurable goal from the 20.** Each pressure has four named goals tied to a strategic outcome (e.g., Growth: "Attract new customers → Drive revenue growth"; Efficiency: "Lower support costs → Reduce support costs"; Operations: "Lead with evidence → Make informed design decisions"). Use the verbatim pairing in `reference.md` so the user inherits the leadership-facing phrasing.
4. **Run the Quick Test on every candidate metric.** A metric is a true *signal* only if all three are yes: (a) Does it prove the design works for users? (b) Does it show adoption or retention at the product level? (c) Does it connect to growth, churn, or revenue at the business level? If any answer is no, it's a vanity metric or a partial signal — name the missing rung.
5. **Flag the three pitfalls explicitly.** Watch for: chasing vanity metrics (clicks/pageviews not tied to adoption or retention), mistaking correlation for causation, and reporting numbers without connecting them to outcomes. If you see one, call it out by name.
6. **Stop at the goal — don't draw the full ladder here.** Once the pressure and goal are named and the metric passes the Quick Test, hand off. Drawing the explicit User Need → Design KPI → Product KPI → Business KPI → Business Goal chain belongs in `glare-lead-mapping`. Translating the goal into a specific function's language belongs in `glare-lead-workflows`.
## Handoffs
- Cross-functional translation of the goal → `glare-lead-workflows`.
- Building the five-rung Chain of Proof → `glare-lead-mapping`.
- Initiatives → Findings → Decisions → Outcomes loop, maturity diagnostic → `glare-lead-results`.
- Broader Lead facet framing → parent `glare-lead`.
- Decision Map area above Lead → `glare-decision-map`.
- Upstream signal collection (Decision Map siblings) → `glare-define`, `glare-measure`, `glare-focus`.
- Signal anatomy and quality (the building blocks anchored here) → `glare-design-signals`, `glare-signals-components`, `glare-signals-types`, `glare-signals-quality`, `glare-signals-capturing`.
- Preparing for or evaluating a leadership review (SIGNAL framework — Surface / Identify / Ground / Navigate / Align / Lock) → `glare-design-review`.
- Assessing team / org design maturity → `glare-design-assessment`.