Building your scorecard. The art is in what you leave off.

We had 23 metrics. That was the mistake.

At its biggest, our scorecard carried twenty-three numbers, and it changed every quarter — usually it sat around fifteen, but it crept upward over time, because scorecards always do. There's a constant gravitational pull toward more: every metric feels important to someone, nobody wants to be the one whose number got cut, and adding a row is easier than defending its removal.

You can see the bloat in the specifics. We had three different flavors of "Application Speed" on the leadership board. We had Weekly Active Users and Weekly Active Users – Multi-session. We had Missed Calls and Average Time to Resolve Tickets — genuinely useful numbers, but support-team numbers, not leadership numbers. The board had quietly become a place where the leadership team reviewed every team's operational detail. That's the trap, and it's worth saying plainly why it's a trap.

A leadership scorecard is a macro view

The right count for a leadership team is about ten to twelve metrics. Not because there's magic in the number, but because that's roughly how many numbers it takes to cover every aspect of the business at altitude — and few enough that the team can actually hold them in their heads and act on them.

The detailed metrics still matter; they just don't belong here. Each individual team should run its own scorecard with the granular numbers for its function — support tracks first-response time and ticket resolution, marketing tracks channel-level traffic, product tracks feature-level engagement. The leadership board sits above all of that. If you find yourself in a leadership meeting reviewing one team's specifics in depth, you've built the wrong scorecard: you've pulled detail up to a level that should be looking at the whole. Fifty metrics on a leadership board isn't thorough. It's a sign you're doing the individual teams' jobs in the wrong room.

What earns a weekly slot — and what doesn't

The test I use for whether a number belongs on the weekly board is simple: does it move week to week, can you see a trend in it, and could you actually act if that trend went the wrong way? If the answer to any of those is no, it's probably not a weekly metric — even if it's a vital one.

The clearest example is unit economics. Numbers like CAC and LTV:CAC are among the most important in a SaaS business, but they're awkward on a weekly scorecard, because calculating them honestly depends on your financial books closing — you need the allocations of sales and marketing cost that only land at month-end. Trying to read them weekly gives you noise dressed up as precision. Those are monthly or quarterly numbers. Putting them on the weekly board doesn't make you more rigorous; it just adds a row nobody can act on for three more weeks.

The before and after

Here's the real comparison — the scorecard as it actually was, and the one I'd build today. Look at what changed, because every move encodes a rule.

The moves that got me from twenty-three to thirteen are the rules, in practice:

Kill the redundancy. Three "Application Speed" rows became one. Two flavors of Weekly Active Users became zero — replaced by Activation Rate and Time to Value, which tell you whether the product is actually delivering value, not just whether people logged in. Duplicate and near-duplicate rows are pure noise on a board this small.

Push the detail down to the teams. Missed Calls, Average Time to Resolve, Seat Downgrades, Expansion Pipeline, Unique Visitors, the self-serve conversion rate — all gone from the leadership board. Not because they don't matter, but because they're team-level numbers. Support owns first-response time on the support scorecard. The leadership team doesn't need it to understand how the business is doing.

Use the right primitive. "Revenue (MTD)" became MRR — recurring revenue is the number that actually describes a SaaS business. Net Churn split into Logo Churn and Revenue Churn, because they answer different questions and a blended number hides both. Weighted Pipeline Size became Pipeline Coverage — a ratio against quota you can actually act on.

Add the few that earn it. I added Quota Attainment, because it's a far better read on sales effectiveness than the activity counts we'd been leaning on — the same reason I'd take it over win rate. And System Uptime, because reliability is a first-class business outcome, not an engineering footnote. Subtraction is the main job, but a leaner board has room for the handful of numbers that genuinely belong.

Start small, and the desert-island test

If you're building your first scorecard, start small and earn your way up. The rule for adding a metric isn't "is this important?" — almost everything is. It's "if this trends the wrong way, can we actually act on it?" If you can't, it's a number to admire, not a number to manage.

And here's the test I keep coming back to for whether the board as a whole is right.

That test does something subtle: it forces you up to the macro level, and it forces a mix of leading and lagging indicators, because you can't predict the next month from lagging numbers alone. Run a metric through it and the answer is usually obvious. Do I need first-response time on the leadership board to know how the business is doing and where it's heading? No — that's a support-team number. Do I need MRR, churn, pipeline coverage, activation? Yes. The desert-island question turns "what should I measure" — which has a thousand answers — into "what would I actually need to fly the plane," which has about a dozen. That dozen is your scorecard. Once you have it, the next job is running the weekly meeting on it.