"Not everything that counts can be counted, and not everything that can be counted counts." — William Bruce Cameron
Throughout the entire Beyond Bedlam process — from the first stakeholder conversation through the technology roadmap — you have been accumulating intelligence. You now have more information about this initiative than anyone who hasn't done this work. Point Analysis is the mechanism for translating all of that accumulated intelligence into a defensible, prioritized decision framework.
It is the answer to the question that always arises at the beginning of implementation: with everything we know, what do we build first, what do we build second, and what do we not build at all?
The Scoring Framework Point Analysis begins with a complete inventory of everything that could be built, changed, or integrated as part of the SaaS initiative. Each item on the list is then scored against a consistent set of criteria. I typically use five dimensions, each scored on a 1 to 10 scale:
Strategic alignment — How directly does this item advance the organization's stated goals? A feature that drives subscriber acquisition for a startup scores higher than a reporting enhancement.
Revenue impact — What is the projected effect on MRR? This includes both direct revenue generation and indirect revenue protection.
Development cost — How much time, talent, and money is required? For this dimension, the scoring is inverted — high cost scores low.
Risk of not doing it — What is the cost of deferring this item? Some features, if absent at launch, will be a constant friction point that generates negative feedback and elevated churn.
Time sensitivity — Is there an external deadline, competitive pressure, or market window that makes the timing of this item consequential?
The total score across these five dimensions creates a priority ranking that the whole team can see, discuss, and refine. The value of Point Analysis is not the score itself — it is the conversation it generates. When a development team and a management team look at the same scored list together, they will frequently disagree on the scores. Those disagreements are the analysis working as designed. The goal is not unanimity — it is shared understanding.
Roadmap Considerations
◆ Build a complete inventory of all potential development items — features, integrations, infrastructure improvements, compliance requirements — before scoring begins. ◆ Establish the scoring criteria and the weighting of each dimension before scoring any individual item. ◆ Score each item as a team, not individually. The discussion that surfaces disagreements is the most valuable part of the exercise. ◆ Review the resulting priority list as a group. Do the top-ranked items match everyone's intuition about what should be built first? ◆ Use the Point Analysis output to drive the first sprint's scope. ◆ Revisit the analysis at the beginning of each major phase — the priority landscape will shift as the product evolves and the market responds.