From a request queue to a product thesis
I reframed prioritization around customer impact, business value, and system health. That gave engineering and business stakeholders one decision language and made deferrals explainable.
- Multi-quarter platform roadmap
- Three new revenue streams
- $20M projected lifetime value
Three teams, one platform, competing definitions of urgent.
The 5G platform powered digital experiences used by millions of customers. Three pressures pulled the roadmap in different directions at the same time.
Business leaders wanted new customer-facing capabilities to defend market position.
Operations wanted recurring failure patterns fixed, because they drove escalations every week.
Engineering wanted dependency and reliability work, because it was the reason commitments slipped.
All three were legitimate. Capacity could fund roughly one of them well. The real problem was not a lack of ideas, it was the absence of a shared way to compare customer pain, revenue opportunity, and platform risk.
The product problem was deciding what not to do, and making that decision durable across teams.
I sequenced platform health first, then growth, on the evidence.
I committed the first phase of the multi-quarter roadmap to the small set of shared platform issues that generated the largest share of support demand and delivery drag, and moved net-new feature work behind them.
The argument was not that reliability matters more than growth. It was that the same engineering hours spent on shared friction returned capacity, and that capacity was the only way the growth work would ship on any credible date.
To make the call reviewable rather than personal, I scored candidate investments on three forms of evidence.
Customer impact
Behavioral friction, failure patterns, and support demand
Business impact
Revenue potential, adoption, and market momentum
System impact
Reliability, scalability, dependencies, and shared leverage
Not everyone agreed, and that was the useful part.
Positions summarized; individuals intentionally not named.
Business stakeholders
Their position
Wanted the customer-facing features first, to protect competitive position in the current quarter.
How it resolved
I showed what current failure and support patterns were already costing in adoption and team capacity, and committed to a dated slot for their features once capacity was released.
A partner squad
Their position
Wanted their own local request fast-tracked ahead of the shared work.
How it resolved
We compared it against the shared capability on the same three criteria. It scored lower on leverage, so it was deferred explicitly, in writing, with the condition that would bring it back.
Engineering leadership
Their position
Wanted a larger re-architecture than the roadmap could absorb.
How it resolved
We scoped the subset that removed the most downstream cost, and staged the rest behind observable triggers rather than rejecting it.
The deferrals were the strategy.
Every deferral was written down with the evidence behind it and the condition that would reopen it. That is what kept the same debates from returning every planning cycle.
I built the decision once, so it could be reused.
The one-off call mattered less than the repeatable process that came out of it.
A shared intake and scoring frame
Any request from any team entered the same evaluation on customer, business, and system impact, so comparison replaced escalation.
A visible deferral log
Everything not funded stayed on the record with its reasoning and its reopening trigger, so no was durable and revisitable.
A dependency and cadence view
Two squads planned against the same sequencing and contingency picture instead of discovering conflicts mid-quarter.
Outcome review, not output review
Each investment was reviewed against the customer, business, or system signal it was supposed to move.
The way other teams asked for work changed.
Requests arrived as escalations, priority followed the loudest sponsor, and deferred work reappeared unchanged every cycle.
Requests arrived with customer, business, and system evidence attached, because that was what got them evaluated.
Two squads planned on a shared dependency and contingency view, and business partners could see where their work sat and why.
The measurable result of that shift shows up in delivery: 30% faster time-to-market, and a critical launch protected by contingency paths agreed before they were needed.
One strategy, four linked outcomes.
Core issues prioritized
Delivery practices aligned
Dependencies and contingencies coordinated
Platform opportunities identified
The deferred growth work shipped in the following phase, on the capacity the platform investment released.
The leverage was not a feature. It was a better decision system.
Data created alignment where opinions could not. Explicit tradeoffs made saying no credible. Shared platform investments gave two squads more room to move.
This is the operating pattern I carry into data and AI products: define the decision, expose the system, align ownership, and measure the outcome.
See my Staff operating model →