Read time: ~6 minutes · Series: Business & Ops practice · Previous: Quick vs formal numbers · Next: Accept Report
You don't read SQL—you read metrics
When an analyst asks you to review Plan, focus isn't JOIN syntax but: which decision this analysis supports and how numbers will be defined. A solid Plan answers the checklist below in business language.
Six checks before Execute
| Check | Ask yourself | Weak signal |
|---|---|---|
| Goal | Which decision does this Plan support? | "Do a funnel" with no decision question |
| Denominator | Numerator/denominator for rates? Cancellations/refunds? | "Active users" undefined |
| Grain | Per order or per user? | Unspecified → double-count risk |
| Time window | Start/end dates; include warmup? | Only "during promo" |
| Stage definitions (funnel) | Filter per stage? | "Order" and "paid" conflated |
| Checkpoints | Steps to sanity-check data first? | Jump straight to final rate |
Any ambiguity → annotate Plan; don't push Execute. Execute means "this metric version is approved for pulls."
Example fields: USER_GUIDE §2.5.
How to read a Plan (suggested order)
- Analysis goal — matches your request?
- Stages / denominator / time window — match business understanding?
- Step outline — no SQL needed; is order sensible (e.g. check NULLs before rates)?
- Questions → select text and annotate, not only verbal feedback
When not to rush Execute
- Plan still Planning and you haven't approved metrics
- Meeting changed definitions; Plan not yet Resolved
- Analyst still exploring fields—that's Quick/explore, not "ship numbers now"
One thing to do now
Open the latest shared Plan; run the checklist; for any fail, annotate with the definition you want (e.g. "denominator = paid orders, exclude cancellations").