What you don't measure before Day 1 you can't prove at Day 30.
By the end of this lesson, you'll be able to capture the right baselines before Day 1, track productivity across four metric categories, and build an ROI story that holds up in a CIO readout.
Baseline capture is the most important data collection moment in the engagement.
The ROI story is written before Day 1. If you don’t have a baseline, you have an anecdote.
The common failure mode is starting the pilot first and trying to reconstruct a baseline from memory or estimates after the fact. That reconstruction is always contested. Sponsors remember the past as better or worse than it was depending on whether they want the pilot to succeed. A captured baseline is objective data. An estimated baseline is a negotiation.
For most Claude Code engagements, two to three data points are enough: PR cycle time from ticket-to-merge for the target use case, self-reported hours on the specific task category, and a developer NPS or satisfaction score. The first two are objective; the third is directional. Capture all three before kickoff.
A baseline captured after the pilot starts is already contaminated. Data collection is pre-work, not post-work.
Four productivity metrics and how to collect them
These four categories come from the Claude Code enablement playbook. Use them to structure both the baseline and the Day 30 scorecard.
New feature development time, prototyping velocity, suggested code acceptance rate. Captured from PR analytics, JIRA, or sprint data. The core productivity story.
First-pass review success rate, security fix velocity, code coverage changes. Captured from PR review data and static analysis tools. Signals whether speed came at a quality cost.
Daily/weekly active users, % using Claude Code after 30 days, hours in tool. Captured from Claude usage analytics. Shows whether adoption is real or nominal.
Developer NPS, qualitative feedback, other-team interest. Captured from short surveys (3–5 questions). Leading indicator for expansion decisions.
One headline number. One business implication.
The Day 30 readout has one job: give the sponsor a number they can repeat in their next leadership meeting.
Choose the one metric from your four categories that most directly reflects the pilot’s use case. For a migration pilot, this is PR cycle time. For a feature build, it’s spec-to-working-code time. State it as a before/after comparison.
Convert the metric to business language. “PR cycle time dropped 34%” becomes “engineering team can ship the equivalent of 1.4x the features in the same sprint.” The translation is what the CIO quotes.
A single page with: use case story (one paragraph), headline metric with before/after, supporting metrics from the other three categories, champion anecdotes, and a proposed Day 60 goal. This is the Activation Summary deck.
The Voxfield ROI Review
Voxfield is a 30-day pilot at an enterprise SaaS company. The use case: new feature development velocity. Day 28. The data is in. Three decisions, up to 6 points.
The data shows: PR cycle time dropped from 8.2 days to 5.4 days (34% improvement). Developer satisfaction went from 6.2 to 7.8 out of 10. Lines of code produced per developer per week increased 55%.
Which metric leads the Day 30 readout?
The headline is “PR cycle time dropped 34%.” Now translate it into business language for the CIO presentation.
Which translation is most defensible?
The pilot data is strong. The CTO asks for your recommendation for the next 30 days.
What’s the right expansion recommendation?
By the end of this course you’ll have a complete Delivery Plan Pack. This lesson contributes the ROI scorecard section.
You can measure the pilot. Now watch it run.
The ROI story is decided before Day 1. Baseline capture, objective metrics, and a precise business translation are what convert pilot data into an expansion decision.