measure-first

Measure First

The plan is only as good as the data it's based on. Static analysis reveals code structure; live data reveals where users actually churn.

When to Use

Activates on any prompt containing "plan", "fix", "improve", "build", "redesign", "add feature", "optimize", "priority".

Before creating any plan or roadmap
Before deciding what to fix first
When asked to build a new feature (should we invest here?)
When the user says "our problem is X" (measure it first)

Procedure

1 — Identify the metrics that matter

Ask: what is the single number that tells us if the product is working?

For a funnel product: activation rate (users who complete step N)
For billing: conversion rate, LTV, churn
For a content product: retention, time-to-value

2 — Query live data

Connect to whatever live sources are available:

Database (SQL, direct Postgres, Supabase, etc.)
Analytics provider (if connected via API)
Logs (Sentry, edge function logs, app logs)
Usage metrics (API rate limits, active users, event counts)

Sample queries:

-- Funnel: how many users complete each step?
select event, count(*), count(distinct user_id)
from funnel_events
where created_at > now() - interval '30 days'
group by 1;

-- State distribution: where are users stuck?
select status, count(*) from cases group by 1;

3 — Let the data reorder the plan

If 86% of cases die at step 1, the funnel is the bottleneck — not the dashboard polish. Sequence the plan accordingly.

4 — Document the bottleneck finding

Measured: [what we found]
Implication: [phase sequence change]
Sources: [DB query / API / logs]

Anti-patterns

Planning based on the order things were requested. The user asked for feature X but the data says Y is the bottleneck — fix Y first.

Planning from the requested order instead of measured impact.
Citing a dashboard number without its date and query.
Optimizing a path only a handful of users reach.

Composes With

verify-first — uses live data as one triangle source
bottleneck-gating — uses this measurement to set phase gates
pushback-when-wrong — delivers the "your order is wrong" message

References

benchmark

Verification Checklist

[ ] The decisive metric and its time window are named.
[ ] The number came from a query or live source.
[ ] The bottleneck finding records what, implication, and source.
[ ] The plan order matches the measured bottleneck.
[ ] Confounders and missing data are stated.

Benchmark Gate

Record samples as JSONL with the workload config beside them. A trace without its config is not reproducible.
Warm up first, drop the first measured sample, and separate wall time from provider-reported time.
A regression requires both a ratio above 1.05 and an absolute delta of at least 0.8 ms. Either alone fails on noise.
Keep the refresh command explicit. Never let a candidate baseline overwrite the committed one silently.
Store success and failure latency separately; a slow failure must not inflate the success estimate.
Key every measurement by model, load bucket, and format version. Pooling across any of them is meaningless.

Install and discovery

Contents