Digital Products — Prioritization Model¶
Purpose¶
This document describes the scoring approach intended to eventually rank the product backlog, once research (see research-backlog.md) produces enough signal to score against. No backlog item is currently prioritized or scheduled. This model exists so that when research starts producing findings, there is already an agreed, consistent way to compare backlog items rather than deciding ad hoc.
Scoring dimensions¶
Each dimension is scored qualitatively (low / medium / high) rather than with a false precision numeric score, since the underlying inputs are themselves largely qualitative until real research exists.
-
Customer problem clarity — How well-defined and specific is the problem this product solves? A vague "helps you manage your finances" scores low; a specific "helps a customer decide between two Social Security claiming ages using their own numbers" scores high.
-
Evidence of real demand — What actual evidence (as opposed to assumption) exists that customers have this problem and would pay to solve it with a structured tool? Starts at low for every item until research produces something.
-
Complexity — How much build effort does the product require, per its expected complexity rating in the backlog (low/medium/high)? Complexity is not scored as "bad" — a high-complexity product can still be worth building — but it factors into sequencing, since lower-complexity, well-validated ideas are generally cheaper to test first.
-
Differentiation potential — Does the product concept have a plausible way to be meaningfully better than existing alternatives (whether spreadsheet templates, competing digital products, or generic advice content), beyond just existing?
-
Research confidence — Once research has been done on an item, how confident is the venture in what was learned (a well-run piece of research scores differently than a quick, low-rigor check)?
-
Reusability leverage — How much of the product can be built from existing or plausible cataloged components (see ../components/component-catalog.md)? Higher leverage lowers the effective build cost of an otherwise-equal idea.
How scores would be used¶
A product should generally not move to the Definition stage of the product artifact lifecycle (see ../docs/architecture/product-artifact-lifecycle.md) until it has at least medium problem clarity and some real (not merely assumed) evidence of demand. Complexity and differentiation inform sequencing among items that clear that bar, not whether an item clears it at all.
Current state¶
No item in product-backlog.md has been scored against this model. All 28 items are pre-research and therefore unranked. Scoring individual items before research has occurred would create false confidence and is explicitly avoided.