Listen and watch now on YouTube, Apple, and Spotify.
In this episode, I’m joined by Eleanor Millman, Senior Staff Product Manager, and Mina Tawadrous, Associate Director of Platform Engineering at SiriusXM, to discuss how platform teams can scale prioritization without relying on revenue.
We talk through how SiriusXM moved beyond RICE to build a custom framework for internal platforms, using weighted factors like developer speed, reliability, cost, and trust to guide decisions across teams.
We also explore their concept of “assumptions as code,” in which teams store and reuse assumptions in a central repository to reduce misalignment and improve decision-making, with AI helping to surface and validate those assumptions.
We close with how this system is shaping SiriusXM’s 2026 prioritization approach and what it signals about a broader shift toward builder-driven product development.
Some takeaways:
Prioritization breaks without a shared system
Prioritization does not scale naturally across teams. What works for one team breaks down at the org level with multiple stakeholders and competing requests
Platform teams lack a clear revenue signal. Unlike product teams, they must prioritize based on indirect impact
A shared framework aligns decisions. Without it, prioritization defaults to local optimization and noise
RICE is a starting point, not a solution
Standard frameworks miss key dimensions for platform teams. Urgency and indirect impact are not captured well
“Impact” needs to be decomposed. SiriusXM broke it into developer speed, reliability, cost, security, and more
The framework must evolve over time. Iteration was critical to making it useful in practice
Weighting forces real tradeoffs
You cannot prioritize everything at once. Increasing one dimension (like cost) necessarily deprioritizes others
Assigning weights makes decisions explicit. Leaders must commit to what matters this quarter
The output drives alignment across teams. A single prioritized list reduces cross-team conflicts
Data and conversation work together
The framework creates a place to attach data. Metrics like reliability scores inform prioritization decisions
Disagreements surface quickly. Teams can see where assumptions or inputs differ
Conversations, not just scores, drive alignment. The value comes from debating inputs, not just ranking outputs
Assumptions are the real bottleneck
Most disagreements come from hidden assumptions. Teams often believe they are aligned when they are not
Assumptions can be conflicting, invisible, or stale. All three create friction in decision-making
Making assumptions explicit improves clarity. It becomes easier to validate or challenge them
Storing assumptions as code scales learning
Assumptions are stored in a central repository. User research and data become reusable across teams
This reduces duplicated effort. Teams don’t need to rediscover the same insights repeatedly
It creates a shared source of truth. Assumptions become visible, versioned, and easier to update
In this episode, we cover:
(00:00) Intro
(01:17) Mina’s role and path into platform engineering
(02:03) Eleanor’s background and shift into product
(03:15) Scaling prioritization across platform engineering teams
(05:41) Aligning platform priorities with stakeholders
(09:08) Evolving RICE into a platform-specific prioritization framework
(11:33) Iterating on the prioritization framework over time
(16:57) How the framework, data, and conversations drive alignment
(19:06) Storing assumptions as code in a central repository
(26:47) Resolving assumption conflicts with user interviews
(30:47) How stored assumptions integrate with AI workflows
(35:30) Standard mode and different user personas
(37:20) The industry shift towards builders
(41:04) The challenges of platform engineering
(43:36) How SiriusXM is prioritizing in 2026
Referenced:
• Measuring AI code assistants and agents
• SiriusXM
• VMware
• How SiriusXM revamped their platform and developer experience
• RICE Scoring Model | Prioritization Method Overview
• The evaporating cloud: A tool for resolving workplace conflict











