Building finance dashboards when nobody writes the spec.
The ask was one sentence: "can we see how revenue and our active customer count are moving?" That was the entire brief. I'm not a finance person, and the requester wasn't going to write a PRD — so the PRD got built backwards. Explore the data first with AI, settle the rules together, write the spec against the working prototype.
1.5 hours assumes the data was already there to query. Engineering had _latest views of every CRM table maintained — I just had to know which ones to JOIN. The hour count is real, but it's running on infrastructure I didn't build.
Synthetic data — same shape as the production dashboard. 11-row structure, BoM = previous EoM, Forecast vs Real distinction.
A one-sentence ask. No spec. No shared definitions.
What I got was one line. No PRD, no taxonomy for what "active customer" means, no reconciliation between Finance's revenue model and CS's logo-flow model. The most important decisions — overlap vs strict boundary semantics, mid-contract churn vs natural expiry, partner deal recognition timing — only surface when somebody draws the actual numbers.
I'm not a finance person. The requester wasn't going to write a spec for me, and even if they had, the spec would have been wrong on the parts that matter. So the PRD got built backwards.
The inverted process.Explore the data with AI — and let it surface the standard definitions you don't yet know exist. Make the best assumption about what the team actually means. Propose a visualization. Settle the rules together by clicking through it. Write the spec last — against the prototype that already shows the answer.
A working dashboard ends every definition argument in five minutes. A spec doc takes a week and ends none of them.— Lesson from the first attempt
Two dashboards. Same source of truth.
Both PRDs share the same deal table and the same "active in month" definition. Finance reads dollars; CS reads logos; the numbers reconcile by construction.
Revenue projection — 12 months forward
Monthly revenue split by Annual / POC / Partner. Drillable to the deal level. MoM attribution for "why did this month move" — new annual, conversion, churn, partner roll-off.
Logo flow waterfall — BoM + Inc − Inact = EoM
Standard waterfall, ~20 months of history and forecast. Every cell drillable: who joined, who left, why. Inactive split into "broke commitment early" vs "expired without renewal."
Five process choices that did more work than any model upgrade.
I'm not a finance person. The things that helped most weren't AI tricks — they were process choices about how to use AI. Each principle below has a working demo from the actual build.
Use AI to upscale the ask. Standard definitions are the missing pixels.
The brief was "show me forward revenue and how customer count is moving." That's a low-pixel image. Before I could even propose a prototype, I needed the structure that turns it into a higher-pixel one — the standard ways finance teams think about this kind of question. AI is fast at surfacing those standards.Not at picking which one fits — that's still my call — but at putting the vocabulary on the table so I can pick.
Once the standards were on the table, the brief became a spec: monthly granularity, overlap-vs-strict boundary semantics, BoM = previous EoM, drivers split across acquisition and churn types. Most of those concepts came from AI's first pass. The rest came from me deciding which trade-offs this team should accept.
"can we see how revenue and our active customer count are moving?"
- Monthly granularity, 12 months forwardMy call
- Revenue split by deal type as separate columnsAI standard
- "Active in month" via overlap boundary semanticsAI standard
- BoM = previous EoM (waterfall closes by construction)AI standard
- Acquisition vs churn as separate driver groupsAI standard
- Forecast vs Real EoM as parallel tracksMy call
- Drilldown on every cellMy call
Build the prototype before writing the spec.
AI is faster at writing a working prototype than I am at writing a clear spec. So I had it build the dashboard first — with real data, fully interactive — then wrote the PRD against the prototype I could click through. Engineers reviewing the spec opened the HTML in their browser and instantly saw what I meant. No "I think you mean..." threads in chat.
The prototype became the alignment artifact, not the spec. The spec became the audit trail.
Engineer's reaction:"Ah, BoM = previous EoM, the waterfall closes by construction. And Real splits from Forecast for current and future months — got it."
Time to alignment: 5 minutes.
Wire drilldowns into every cell. SQL shouldn't be the bar — for QA or for end users.
Drilldowns do double duty.The prototype isn't just a visualization — every number drills into the customer set behind it. That serves two audiences at once.
For me during the build: I verify the spec one click at a time without writing SQL. When a cell looks wrong, I click. When it looks right, I move on. The spec gets locked cell by cell.
For the end users who'll live with this dashboard:they're CS reps and finance analysts, not data engineers. They don't write SQL either, and they aren't avid AI users. They want to know who's the −2 in March without a Slack thread to me. Drilldowns meet them where they are— every number is its own QA tool, every QA tool is the answer to a future question they haven't asked yet.
AI makes building this kind of empathy layer cheap. That cheapness is what lets me afford to treat every number as a future user's question and answer it before they ask.
"Which two? When were they signed? Were they mid-contract or natural expiry? Does that match what we know about them?"
Treat AI's first answer as a draft to push back on.
The first version of the customer-churn classifier was confidently wrong. It pulled signal from a deal record that lived outside the scope I'd defined — technically related, but in a different pipeline. AI had no way to know that constraint. I caught it because the prototype showed me Customer A's classification didn't match what I knew about them.
The pushback isn't "AI is wrong." It's "show your work, and I'll spot the leaks." Below is the actual iteration arc — four versions, the human feedback that drove each, and what eventually shipped.
v1 — Use the parent deal's churn date
If the customer's parent record has a churn date set, mark them as broke-contract early. Otherwise, expired naturally.
Customer A shouldn't be mid-contract churn — they completed twelve months. Why is the parent date even in scope here?
Real data from minute one. Lorem ipsum lies.
Mocked data shows what looks pretty. Real data shows the bugs that matter — boundary cases, off-by-one date math, a customer whose contract ends on the 31st and renews on the 1st. None of that surfaces in fake data. All of it surfaces in five minutes against the actual database.
Hover over each row below to see a real bug that only appeared because the prototype was wired to production data on day one.
| Customer | What the prototype showed | |
|---|---|---|
| Customer EQ | Contract ends Mar 31 → didn't appear in April's "Inactive" row | boundary |
| Customer SH | Marked as "Returning" in April → had two consecutive deals with no gap | phantom-gap |
| Customer SS | Flagged as mid-contract churn → completed full 12-month contract | scope |
| Customer GR | Wrong company name shown → CS had renamed it three weeks earlier | stale-source |
What this is and what it isn't.
I want this to be useful, not aspirational. Here's the version that doesn't oversell.
What this is
- An operator without finance training shipping infrastructure that the finance + CS teams are now using to align on numbers in minutes instead of half-days.
- Proof that the bottleneck in AI-powered work isn't the model — it's whether the person driving it has a calibrated sense of what good looks like.
- A reusable methodology: prototype before spec, push back on the first draft, real data day one, document the trade-offs.
- A rule for the spec itself: the work is auditable end-to-end. Anyone can re-derive the dashboard from raw tables.
What this isn't
- Not "AI replaces the analyst." Every口径 decision was a human call. AI implemented and surfaced trade-offs; I picked which trade-off to ship.
- Not "I learned finance in a weekend." I leaned hard on the engineering team for the data layer and on a colleague for what auditability actually means in practice.
- Not perfect. The shipped churn rule mislabels at least one real customer — I documented it rather than hide it.
- Not a one-shot demo. This is the seventeenth or so iteration of "use AI to ship operational tooling without waiting for the eng roadmap." Each one taught the next.