Walk me through your actual prioritization framework. Not the acronym — show me how the next quarter’s roadmap gets decided in practice.?

The full executive answer

The scoring is RICE — Reach, Impact, Confidence, Effort — but what makes it honest rather than theatrical is where the inputs come from, because pre-revenue Reach estimates are usually fiction. Ours are instrumented: the expansion-signals engine logs every time a user clicks a feature their tier locks — the strongest possible "reach" evidence, an actual hand raised against a wall. Funnel and cohort analytics show where journeys stall. The NPS module captures scored feedback with verbatims. Win/loss records on pipeline opportunities capture what buyers said was missing. Those four streams are the Reach and Impact columns of the RICE sheet.

On top of the scores sit two overrides. Commitments: anything sold to an Enterprise design partner is a Must-have in MoSCoW terms and jumps the queue — pre-revenue, a paying partner’s committed need outweighs any model. Invariants: security, tenant isolation and the quality gate are never traded for features; the CI pipeline enforces that structurally, so the roadmap cannot vote to skip them. Confidence scores stay brutally low until real usage data exists — that is the discipline that stops founder enthusiasm from masquerading as evidence.

Cadence: monthly re-score, quarterly theme selection, and everything shipped lands in the public changelog, so the roadmap is auditable against what actually happened. The underlying philosophy is Jobs-to-be-Done — modules exist because a board-level job exists, and the roadmap question is always "which underserved job next", not "which feature is coolest".