# Calling the Status Honestly — the Watermelon Problem

The most common failure of stakeholder updates isn't structure — it's watermelon status: green on the outside, red on the inside, discovered three weeks too late. This reference is the calibration for the 🟢/🟡/🔴 call and the wording for delivering the bad ones.

## The status is a forecast, not a mood

Status answers one question: **"Will this land as committed without intervention?"** — not "how hard is the team working" or "how do I feel about it".

| Call | Means | Test |
|---|---|---|
| 🟢 On track | Lands as committed; no risk needing stakeholder awareness | You'd bet your credibility on the date *and* nothing on the risk list keeps you up at night |
| 🟡 At risk | Lands only if something breaks our way, or scope/date needs a small trade | There is a named risk with a probability worth writing down — 🟡 always comes with *the* risk, not vibes |
| 🔴 Blocked / off track | Will not land as committed without intervention or a re-plan | The ask is mandatory: a 🔴 without a specific "need from you" is just alarm |

## Rules that prevent watermelons

- **Two consecutive 🟡 on the same risk = escalate or re-plan.** Chronic yellow is red wearing makeup. Either the mitigation is working (say what changed) or it isn't (call it red and ask).
- **Status can't improve without an event.** 🟡 → 🟢 requires naming what resolved. "Back on track" with no cause means the yellow was never real — or the green isn't.
- **Slipping the date resets the status against the *original* commitment** in the update where it slips: "🔴 against Feb 5; proposing Feb 19, 🟢 against that if approved." After stakeholders accept the new date, track against it. Silent re-baselining is the watermelon's favourite move.
- **Metrics and status must agree.** Three red metric rows under a green banner reads as either inattention or spin. If the metrics are red and the status is green, explain why (leading vs lagging), or fix the status.
- **The first bad update costs the least.** Every cycle a risk stays hidden, the eventual disclosure costs more credibility. Executives don't punish early yellows; they punish surprises.

## Delivering bad news — phrasing that works

The formula: **fact → impact → what we're doing → the specific ask.** No softening preamble, no blame, no "unfortunately".

- ❌ "Unfortunately due to unforeseen circumstances there may be some delay."
- ✅ "Payment-provider API deprecation costs us 2 weeks. Launch moves Feb 5 → Feb 19 unless we cut the invoicing scope — decision needed by Friday."

- ❌ "We're a bit concerned about capacity."
- ✅ "We lose our only iOS engineer to [X] on Mar 1. Without a backfill decision by Feb 10, the mobile milestone slips a full sprint."

Softening rules for the whole update:
- Delete hedges around facts ("somewhat", "may potentially", "it seems"). Keep uncertainty only where it's real, quantified: "60/40 we make the date".
- Never pre-blame ("as flagged previously…" reads as covering yourself; if it matters, restate the risk plainly).
- Pair every problem with the *decision it creates* for the reader. Bad news without an ask is venting; bad news with an ask is management.

## When you inherit a watermelon

Taking over something reported green that is actually red: reset in your *first* update — "after review, I'm calling this 🔴 against the June date; here's the honest baseline" — with a re-plan attached. You get exactly one free re-baseline as the new owner; spend it immediately.
