Every project presented to stakeholders needs to answer two questions, and only two:
Problem
What is the problem worth solving for our users? What will the user do, or do better, that they can't already?
Value
What is the value of solving this for us? Organised and presented through a standardised scorecard.
The technology to be used is always secondary. User-focused technology is a means to an end; it takes the back seat. The scorecard is the mechanism that forces this discipline, because when every project is scored on the same axes, no one can smuggle in a pet feature dressed up as strategy.
The value of the scorecard isn't the number. It's the conversation you have while scoring. When two people disagree by 3 points, that's where the real discussion lives.
Matrix 1 · The Business Scorecard
Use this for any project that touches customer-facing value, new features, product launches, upsell opportunities, compliance-driven work.
Business Scorecard
Customer value · Seven dimensions · 0–40 total
How the weightings work
Two dimensions carry 0–10 and the other five carry 0–5. That's deliberate. Innovation and Contractual obligations are weighted higher because they're the two places where "no" has the biggest downstream cost, you either miss the market or you breach your SOW.
Matrix 2 · The Technical Project Scorecard
Use this for technology and architecture work, scalability, quality, reliability, technical debt. Things like switching to a new framework, adding automated testing, or decoupling services.
Technical Project Scorecard
Engineering health · Eight dimensions · 0–40 total
Why Security carries double weight
Of the eight technical dimensions, only one sits at 0–10: Security. It's the only line item that can by itself justify a project. A 7/10 on security with zeros everywhere else is still a worthwhile investment. The inverse is rarely true.
A worked example
Imagine you're choosing between two proposals for the next quarter. Here's what the scorecard reveals.
Using the scorecard in practice
Score together, never alone
The scorecard should never be filled in by one person. At minimum: Product, Engineering, and a Champion from the user side. Disagreements are the feature, not the bug.
Calibrate your scores
A 10 on innovation should mean something. If every project scores 8-10 on every axis, the scorecard has become a rubber stamp. Revisit your last five scored projects quarterly. Are the rankings still defensible?
Don't mix the two matrices
Business and technical scores are both out of 40, but they're not the same currency. A business 32 isn't "better than" a technical 30. Present them side by side, not as a single total.
Let "No" be a real answer
The scorecard is also a filter. If a project scores below 15/40 on both axes, the right answer is usually not "later". It's "no, thank you". Parking things indefinitely clutters the roadmap.
Watch out for Score inflation around favourite projects. If you find yourself negotiating with the scoring to reach the total you want, the conversation has already gone wrong. Trust the number, then decide if you want to override it, but override it consciously.
What to read next
The scorecard is what goes into the Value section of the Solution Document. And once your project is scored and approved, you'll need a plan for communicating it to the people who care about it most.