Skip to content

Prediction Naming to Client

"We expect X. We will check on date Y. We will tell you the result." Predictions are made out loud. Not as a forecast to defend, but as a model to correct — alongside the client.

Owners: PO Phase it lives in: Before We Build → How We Build → After We Build The corpus principle this enacts: A prediction not checked is indistinguishable from a guess — and a prediction not shared is a guess the client doesn't get to test against.

Where it lives in the chain

How to do this

The prediction shared with the client has three lines, no more:

"After we ship the grading shortcut on 2026-05-25, we expect Gal's grading session to drop from 47 minutes to under 15 minutes. We will check this on 2026-06-25 and share the result with you."

That is the whole communication. Not a slide. Not a marketing claim. A factual statement of a model and a commitment to test it.

What good practice looks like

The PO names the prediction in the bi-weekly sync at the start of the cycle. The client reads it in the weekly update as the cycle progresses. The result lands in the next bi-weekly sync after the check date — predicted X, measured Y, here's what we learned.

The client becomes a participant in the loop, not a recipient of the output. That participation is what makes the relationship a chain conversation.

A team that hides predictions until they're confirmed has nothing to share when they aren't. They show up to the bi-weekly sync with euphemisms ("we're seeing some adoption challenges") and the client recognises the smell. Trust erodes faster than any feature can rebuild.

A team that shares predictions and shares the results — including the wrong ones — builds a track record. "We predicted 15 minutes; it came in at 22. Here's what we learned and what we'll adjust." That is the most persuasive sales document the team will ever produce.

200apps · How We Work · NWIRE