Context
Every case on this site ends the same way if you zoom out. Data existed but wasn't connected. Official process differed from actual process. Employees quietly became infrastructure. Reporting created confidence without shared meaning. Teams optimized locally while revenue failed between them.
For years these looked like separate problems with separate names, belonging to whichever company I was standing in.
What Looked Broken
Each organization believed its problem was local and functional: a marketing problem, a CRM problem, a reporting problem, a sales-handoff problem.
What I Noticed
The failures were structural, recurring, and mostly located between functions — which is exactly where nobody's job description points. When the same five or six failures keep appearing in education, healthcare technology, B2B data, and cybersecurity, the explanation isn't coincidence. It's architecture.
The Actual Constraint
There was no instrument. A company could get a marketing audit, a sales audit, a CRM health check — each one examining a single organ. Nothing evaluated the revenue system as a system: the dependencies, the handoffs, the places where locally healthy functions produce globally broken outcomes.
My Hypothesis
The recurring failures could be organized into a finite, learnable structure — and if they could, an organization should be able to assess the health and dependencies of its entire revenue system before prescribing tactics.
What I Architected
The Revenue Health Matrix: five interconnected systems — Positioning, Authority, Conversion, Lifecycle, Visibility — decomposed into 50 child systems and roughly 200 evaluation areas. Every evaluation area is documented with a definition, the evidence to look for, what good looks like, and its common failure modes. Cross-cutting the systems: the four structural patterns this site uses as tags — Visibility Debt, Coordination Friction, Shadow Systems, Founder Blindspots.
Then the operational layer: snapshot and deep assessments, scoring logic, and the diagnostic maps (failure, dependency, critical path, pressure, symptoms, financial drivers) plus a KPI library.
What I Personally Built / Did
Honest attribution, because this is the case that claims I can build:
- Mine, by hand: the framework itself — taxonomy, question design, evaluation criteria, scoring methodology, all ~200 documented areas. It started as 37 spreadsheets and pivot tables. Also the information architecture, the product logic, and the data model: I converted the spreadsheet system into a Supabase database myself.
- Mine, AI-assisted, and labeled as such: I gave Claude an illustration I made and had it generate a CSS/JSX prototype of the interface; I handed that prototype to Lovable, which wrote the UI code against my database. I directed, tested, and corrected; the AI wrote the interface code.
I'm precise about this split because "built with AI assistance" is either honest or it's résumé inflation, and this site doesn't do the second thing.
What Happened
A working product exists: the framework, the assessment, the scoring architecture, and the application on top of my schema. I'm equally precise about stage: this is a functioning diagnostic and methodology, not a business with traction numbers I could wave around. The result I'm claiming is the artifact itself — and the professional behavior it demonstrates: encounter a recurring class of problem, abstract the pattern, design the architecture, build the thing.
What Became Possible
I can now walk into an organization with an instrument instead of an intuition. And the diagnosis conversation changes: instead of "I think something's off in your handoffs," it's a specific evaluation area, with defined evidence, and a map of what depends on it.
What I Learned
Abstraction is a building skill. The framework took longer than the software, and it should have: the software is an interface to the thinking, and no amount of AI acceleration fixes thinking that hasn't been done.
Evidence / Artifacts
Framework documentation workbook (5 → 50 → ~200 structure, with definitions and failure modes), application screenshots, structure diagram, and — if recovered — the interactive Matrix prototype.
document / Strategy & Architecture
Revenue Health Matrix — Framework Documentation
The full framework: five systems, fifty child systems, and roughly two hundred evaluation areas, each with a definition, evidence to look for, what good looks like, and common failure modes.
The thinking layer. It took longer than the software, and it should have.
application / Product & Software
Interactive Revenue Health Matrix
Interactive HTML explorer of the five revenue systems, their child systems, and the evaluation areas beneath them.
Interactive prototype of the diagnostic structure.
Related Work
Where the pattern was learned: every other case on this site, but especially The Missing Middle and The Build Wasn't the Problem. The beliefs underneath: the Revenue Architecture Manifesto.