What Has to Be True

---
name: what-has-to-be-true
description: >-
  Point it at a target — a revenue goal, a board commitment, a number you're
  planning a raise around — and it reverse-engineers the growth, hiring, and
  margin path required to hit it, then flags which of those implied
  assumptions are realistic against your trailing history and which are a
  stretch. Turns "can we hit this number?" into a testable, falsifiable set
  of assumptions instead of a gut feeling. Use whenever someone has a target
  number and wants to know what it actually requires, or wants ammunition
  before agreeing to a number someone else proposed. Triggers include "what
  has to be true", "can we hit this target", "reverse-engineer this number",
  "work backward from this goal", "is this target realistic", "what would it
  take to get to [X]", or naming a specific commitment (an ARR target, a
  board number, a raise-round target) and asking whether it's achievable.
metadata:
  author: "Aleph - getaleph.com"
  version: "1.0.0"
---

# What Has to Be True

## What this skill does

Most target numbers get discussed as a single question: can we hit it, yes
or no. That question is unanswerable on its own — a target isn't realistic
or unrealistic in the abstract, only the specific path to it is. This skill
never answers "yes or no." It answers **"here's exactly what has to happen,
and here's how that compares to what's actually happened before."**

The method is the finance-team version of Michael Mauboussin and Alfred
Rappaport's *expectations investing*: reverse-engineer the assumptions a
number implies, rather than building a forecast from scratch and comparing.
Applied to an internal target instead of a stock price, the same logic
holds — decompose the target into its drivers, solve backward for what each
driver has to hit, and grade the result against trailing reality.

## When to use it

- A board, investor, or leadership has proposed a target and you need to know
  what it actually requires before agreeing to it.
- You're planning a raise, a hiring plan, or a budget around a number and
  want to pressure-test it first.
- Someone asks "can we hit $X by Y" and you want a real answer, not a guess.

## Inputs

- **The target** — a number and a date. A revenue/ARR goal, a board
  commitment, a number a raise is being planned around.
- **Optional: trailing actuals** — historical ARR, headcount, and margin
  data. Without it, the skill can still decompose the target and reason
  about the drivers, but it can't grade them against real history — say so
  explicitly if trailing data isn't provided.

If neither trailing actuals nor a current baseline number is provided, ask
for current ARR/revenue — ideally 12 months of actuals — before producing
the graded report. Never substitute industry benchmarks or an invented
baseline for the company's own history. Only if the user confirms there's
no history to give should the run proceed as decomposition-only.

## Workflow

1. **Break the target into its driver components** — using
   `references/methodology.md`, decompose the target into growth (net-new
   ARR or revenue required), hiring/capacity (what that growth requires in
   headcount, given current productivity), and margin (what the resulting
   cost structure does to burn or profitability).
2. **Solve backward for what each driver has to hit** — work from the target
   to the required value of each driver, showing the arithmetic, not just
   the conclusion.
3. **Compare each implied driver against trailing history** — pull the
   actual trailing growth rate, net-new-ARR-per-rep, hiring pace, and margin
   trend from the provided actuals, and set each implied driver next to it.
4. **Classify and flag** — per `references/methodology.md`, grade each
   driver **In-line / Aggressive but plausible / Stretch**, and name the
   single lever that would most reduce the stretch if relaxed.

## The methodology

The full decomposition method, the grading bands, and the "biggest lever"
technique live in `references/methodology.md`. Apply it exactly — the value
of this skill is a consistent, falsifiable breakdown, not a vibe check.

## Output format

Always return the result in the structure defined in
`references/output-template.md`: the target restated, the driver
decomposition table, the overall verdict, and the single biggest lever.

## A note on scope

This skill reverse-engineers a target into assumptions and grades those
assumptions against history. It does not build the operating plan that
would deliver the target — once the assumptions are agreed, that's a
forward-planning exercise (a headcount plan, a budget), which is a separate
job.

# Reverse-Engineering Methodology

Apply all three parts below, in order, to every target.

## 1. Decompose the target into its drivers

A target is never one number — it's the output of at least three drivers.
Solve backward for each before saying anything about feasibility.

- **Growth driver — required Net New ARR (or revenue).**
  `Required Net New = Target − (Beginning ARR × (1 − assumed gross churn))`
  Over a horizon longer than one period, compound the monthly gross churn
  rate over the full horizon: `Beginning ARR × (1 − monthly churn)^months`.
  If no churn assumption is given, use the trailing actual gross churn rate
  from the actuals; if none is available, state the assumption explicitly
  as a gap rather than silently assuming zero churn.
  Convert this into a required **CAGR or period-over-period growth rate**
  from the current base — this is the number people actually feel.

- **Capacity driver — required hiring/headcount.**
  `Reps required = Required Net New ARR / trailing net-new-ARR-per-fully-ramped-rep`
  Compare the *pace* of hiring this implies (reps needed ÷ months available,
  net of ramp time) against the company's trailing hiring pace. A target
  that pencils on headcount alone can still be impossible on hiring pace and
  ramp time — always check both. Count a new hire as 0% productive for the
  stated ramp period and 100% after; if ramp time isn't known, state it as
  a gap rather than assuming day-one productivity.

- **Margin driver — the cost/burn implication.**
  Headcount growth implies opex growth. Roll the required headcount into
  the cost structure and solve for what happens to gross margin, EBITDA
  margin, or burn under the plan. A target can be achievable on growth and
  hiring and still be a bad idea on cash — say so if the math shows it.

## 2. Grade each driver against trailing history

For each of the three drivers above, compare the *required* value to the
*trailing actual* trend, and classify:

- **In-line** — within a normal continuation of the trailing trend (required
  pace no more than ~1.25x the trailing rate, directionally consistent).
- **Aggressive but plausible** — meaningfully above trend (between ~1.25x
  and ~2x the trailing rate), but there's a concrete, named catalyst that
  would explain the acceleration (a new product motion, a channel that just
  opened, a pricing change already taken). Aggressive without a named
  catalyst is a flag, not a pass.
- **Stretch** — required pace at or above ~2x the trailing rate absent a
  named catalyst: a discontinuity from trailing performance with no stated
  explanation. Name the specific gap (e.g., "requires net-new-ARR-per-rep
  to be 2.4x the trailing average" or "requires hiring at 3x the pace ever
  sustained").

Always show the actual numbers side by side — the required value and the
trailing value — so the classification is falsifiable, not asserted.

## 3. Find the single biggest lever

Of the three drivers, identify **which one, if relaxed even slightly, would
most reduce the overall stretch** — a later date, a lower target, an
assumption on churn or productivity that's currently pessimistic. This is
the material the target-setter actually needs: not just "this is hard," but
"this specific thing is why, and here's the cheapest way to make it easier."
If the target is at or below trend, say so and quantify the headroom —
don't manufacture a lever where none is needed.

## Calibration

- Do the arithmetic explicitly. A reader should be able to check every step.
- Don't round a stretch into "aggressive" to be diplomatic, and don't call
  a genuinely in-line target a stretch to sound rigorous. The classification
  only has value if it's honest.
- If trailing actuals are thin or missing for a driver, say so — a driver
  graded on no data is a gap in the analysis, not a green light.

# What Has to Be True — Output Format

Always produce the output in exactly this structure and order.

---

## 🎯 What Has to Be True

**Target:** {the number, restated, with the date}
**Starting point:** {current ARR/revenue, current headcount, as of when —
or "not provided — requested" if there's no baseline}
**Overall verdict:** {one of — 🟢 In-line with history · 🟡 Aggressive but
plausible · 🔴 A stretch without a structural change · ⚪ Cannot grade — no
trailing history provided (decomposition only)} — one sentence why.

---

### The decomposition

| Driver | Required | Trailing actual | Classification |
|---|---|---|---|
| Growth (Net New ARR / period growth rate) | {value} | {trailing value} | {In-line / Aggressive but plausible / Stretch} |
| Capacity (reps needed, hiring pace) | {value} | {trailing value} | {In-line / Aggressive but plausible / Stretch} |
| Margin (resulting EBITDA/burn impact) | {value} | {trailing value} | {In-line / Aggressive but plausible / Stretch} |

Show the arithmetic behind each "Required" figure — not just the number.

---

### 🔧 The single biggest lever

{Name the one driver that, if relaxed, most reduces the overall stretch, and
what relaxing it would look like — a later date, a lower number, a
different assumption — with the resulting required values if that lever
moves.}

---

### What's missing

{Name anything that couldn't be graded because trailing data wasn't
available, rather than silently skipping it.}

---

*Use this to negotiate the target, not just to hit it — when a number came
from someone else's spreadsheet, this is the leverage. Want help drafting
the counter-proposal?*

WHAT THIS FILE IS
=================
what-has-to-be-true.skill — Reverse-engineers what a target number requires and grades each driver against your history.

A .skill file is Anthropic's packaging format for Claude Skills. It is a
standard ZIP archive, nothing more. If you are reading this in a text
editor, you are looking at the raw bytes of that archive — this build is
intentionally uncompressed so the contents stay human-readable.

LOOK INSIDE YOURSELF
====================
Rename the file from .skill to .zip and extract it, or run:  unzip what-has-to-be-true.skill
Every file inside is plain-text markdown — the instructions Claude reads.
There is no executable code in this package.

WHAT'S INSIDE
=============
  SKILL.md
  references/methodology.md
  references/output-template.md
  README.txt (this file)

HOW TO USE IT
=============
Upload this file as-is to Claude: Settings -> Skills -> Add.
Or add it in Claude Cowork or Claude Code.

From Aleph (getaleph.com), the FP&A platform.
The full guide: https://www.getaleph.com/claude-skills-library
Questions: marketing@getaleph.com