How We Prioritize

Input Sources

Prioritization decisions are informed by multiple signals, not any single source:

• Customer feedback - Direct conversations, support tickets, feature requests, and churn reasons. Weighted by ARR and strategic importance.
• Usage data - What features are actually used, where users drop off, what workflows are friction-heavy.
• Sales signals - What capabilities come up repeatedly in deals? What are we losing deals over?
• Research insights - New techniques from our research team or the broader AI safety community that could unlock product capabilities.
• Competitive landscape - What are others building? Where are the gaps?
• Technical debt - Infrastructure and code quality issues that slow down future development.

No single signal dominates. The best prioritization decisions synthesize multiple inputs.

The Framework

We use a lightweight ICE framework adapted for our context:

• Impact - How many users does this affect? How much value does it create? Does it unlock new use cases or improve existing ones?
• Confidence - How sure are we about the impact? Is this based on data from 50 customers or a hunch from one conversation?
• Effort - How long will this take? What’s the engineering complexity? Are there dependencies?

We score each dimension roughly (high/medium/low), then use judgment - not a formula - to make the final call. Spreadsheet-driven prioritization creates an illusion of objectivity. We’d rather be honest about the judgment calls.

Roadmap Cadence

• Quarterly planning - Set themes and major bets for the quarter. These are directional, not prescriptive.
• Weekly prioritization - Teams review and adjust their backlogs weekly based on new information.
• Public roadmap - We maintain a public roadmap at /roadmap showing what’s in progress, what’s next, and what’s shipped.

Saying No

The hardest part of prioritization is saying no. We say no to:

• Features that serve one customer but not the broader base
• Nice-to-haves that don’t move key metrics
• Requests that conflict with our design principles
• Scope creep on in-progress work

Saying no isn’t permanent. It means “not now” - and the reasoning is documented so it can be revisited.