Why I wanted it
Which of two flows to build. Whether a module was worth the rework. Whether the thing a customer complained about on Tuesday was a real problem or one person having a bad week. I settled those with judgment, customer conversations, and whoever in the room had the strongest opinion, and I was usually right. It did not scale past me, and it did not survive a disagreement with someone senior.
Underneath that was a second problem. Every design I finished went into a queue behind work that carried a revenue number. Engineering hours were quantified down to the sprint; the return on what I wanted those hours spent on was not quantified at all, so my work lost the ranking by default.
Both problems have the same fix, so I made the case for product analytics and got the budget.
Building it
I made the case for Pendo, got the budget, and became its sole administrator. I wrote the initialization code for five products across two companies, defined the event taxonomy, and built the connection between Pendo and Salesforce so usage could be read against revenue. It was the first feature-to-revenue attribution the company had.
Instrumenting a workflow that spans six screens and three roles is not a tagging exercise. It meant reading each codebase well enough to know where the meaningful boundaries were, which is the part of the CS degree I still use. The custom events got specific enough that Pendo’s own product team asked what I was doing with them.
The Salesforce side I built with Andrew Zellis in revenue operations, and that half mattered as much as the instrumentation. Usage data on its own tells you what people do. Joined to account records, it tells you what a feature is worth, which is the number a proposal needs to compete for engineering time.
Athen’s product analytics were the first time we could tie usage to accounts in a way that reconciled with what we saw in the pipeline. During the federal contraction we were pulling his usage data into renewal conversations directly — it flagged accounts at risk weeks before anything showed up in our own numbers.
Andrew ZellisDirector of Revenue Operations, OPEXUS
What it showed
In January 2025 Thoma Bravo merged OPEXUS with Casepoint, which meant deciding what to keep and what to cut across two overlapping suites. FOIAXpress had three major modules: Case Processing for intake and workflow, Document Management as a repository, and the Document Viewer for review and redaction. We supported all three equally and sold all three as core, on the reasonable theory that the FOIA process is linear. If agencies used Case Processing, they would use the rest.
Case Processing was used heavily, as expected. Document Management and the Viewer sat in the 12 to 18% range at many accounts. Agencies were using our core workflow and doing the rest elsewhere. We had been staffing and selling all three on an assumption that was only true of one.
Whether to soften it
I did think about softening the chart. There was a grouping that would have made the gap look like variance instead of a verdict, and it would have been an honest chart.
It went out unchanged. I had spent a year arguing the company should decide from data, and the first time the data was inconvenient was not the moment to start adjusting the presentation.
The room challenged the tracking before it challenged the finding. That is what happens when a number contradicts three years of belief, and it is a reasonable place to start. I had the reconciliation ready because Andrew and I had built it months earlier for the revenue modeling: our usage counts lined up with the account records revenue operations kept independently, on accounts nobody was arguing about. We went through those first, and after that the conversation moved on to what the adoption number meant.
The case for Casepoint moved off the overlapping repositories and onto the part agencies actually struggled with, which was finding and reviewing records. It redirected my own roadmap too. I stopped proposing improvements to the Viewer and started designing for the workflow people were running.
$10M in at-risk revenue
In early 2025 the Department of Government Efficiency reductions hit our customers. Agencies lost 30 to 40% of staff, which put our per-seat model directly at risk.
Because the tracking was already running across every product, we could size it in days. I segmented accounts by usage trend, overlaid policy events against the drops, and identified more than $10M in at-risk ARR, early enough to inform the pricing revision and to hand account teams a list of who to call first.
What I took from it
I had the reconciliation ready before I needed it
I knew the first uncomfortable number would get the instrument questioned before the finding did, because that is what always happens. So the Salesforce cross-check existed months before the meeting where it mattered. Building the defense of a measurement at the same time as the measurement is the part I would repeat anywhere.
I would not tell every designer to do this
Owning the instrumentation cost me about a day a week that I would otherwise have spent designing. It paid off because nobody else was going to do it and because I could write the code myself. At a company with a data team I would have spent that day writing better questions for them instead, and I would have been more useful.