A complexity budget for scope decisions

We stopped debating polish and started questioning cost.

The Challenge

Our core features weren’t delivering. We responded with feature improvements. Yet each one had to honor the expectations set by earlier designs. There was no clear process for reevaluating what still mattered. Every addition carried the weight of legacy edge cases, regressions, and integrations.

Research was used to justify features, not reduce complexity. Teams tried to add value from their own vantage points, but without a shared model for complexity tradeoffs, forked flows, overlapping logic, and edge-case coverage became our operating model.

Everyone agreed simplicity mattered. But we lacked a shared way to prioritize what was essential or measure what users could reasonably absorb. Instead of questioning what belonged, we focused on organizing it through layout, hierarchy, and visual polish. Simplification became a late-stage clean-up effort. It was well-intentioned, but too late to change what shipped.

My Response

I realized we couldn’t reduce complexity without first making it measurable. So I led the creation of a shared framework that redefined simplicity as a cross-functional constraint—not a design aesthetic. We grounded it in cognitive effort and user behavior, translating friction into guidance teams could act on.

The core of the framework was a complexity budget—a constraint model that treated complexity like technical debt: it accumulates quietly, erodes the experience over time, and can only be reduced through better decisions earlier in the process. It defined how far a flow could push before it became too much to absorb—too many decisions, too many clicks, too many places to go. The framework changed how teams scoped. We stopped debating polish and started questioning cost. What friction were we adding? Was it worth it? The questions shifted—and so did the outcomes. We built the model into planning cycles. Researchers surfaced recurring friction patterns. PMs mapped effort and alternatives. Designers used the budget to prioritize, challenge scope, and make reductions defensible.

The Win

The complexity budget gave teams a credible way to recognize when scope had gone too far—and a shared language to scale it back. Teams could justify reduction not by opinion, but by impact. Simplification happened earlier, and we shipped leaner.

What it changed about planning

Design didn’t just join earlier. We changed the shape of planning. Roadmaps reflected more complete problem definitions. Priorities shifted as design clarified user value earlier in the process. Engineers worked with fewer blockers. PMs scoped more effectively. And designers became known not just for execution, but for improving how decisions were made. Decisions that drove measurable efficiency gains and consistent lift across the product roadmap pipeline.

Key Outcomes

1. Reframed simplicity as a measurable constraint across product decisions
2. Standardized how teams evaluated scope, tradeoffs, and user effort
3. Equipped teams to identify scope bloat and defend reductions with impact
4. Shifted simplification upstream, reducing late-stage rework and overbuild