Fixed Timeline, Variable Scope — Part One
Your company is likely caught in a common trap: overplanning innovation. It leaves product leaders frustrated by missed deadlines, engineers overwhelmed with endless work, and executives suffering whiplash from fluctuating roadmaps.
In this series, I’ll make the case for rethinking how we approach software innovation. In part one, I’ll break down why the industry standard is broken and introduce a new framework. In part two, I’ll show you how to put this framework into action. And in part three, I’ll share insights from six years of applying it with real teams.
The Innovation Spectrum
Product development boils down to two types of work: innovation and execution.
Innovation is ambiguous. The product vision might exist, but it’s often fuzzy, and the path forward is unclear. This work pushes the product into uncharted territory.
Execution is straightforward. The path to completion is clear, and everyone knows what to do. This work builds on existing ideas.
Most projects fall somewhere along the spectrum between these two extremes.
The Industry Standard
The age-old script goes like this: product asks, “how long will this take?” Engineering answers with an estimate. Spoiler alert, that estimate is probably wrong.
This process works well if the work skews heavily toward “execution” because product knows precisely what they want and engineering knows exactly how to get there. The estimates provided are reliable.
Engineering estimates are rarely reliable because most projects don’t lean entirely toward execution. Businesses don’t succeed by reinventing the wheel, and it’s antithetical for an agile process to specify work months or years in advance. So, when engineering provides an estimate it gets padded, or research tickets are created, or they are otherwise just wrong.
Having built dozens of 0→1 products, I’ve learned a hard truth: achieving ±10% accuracy on a six-month estimate requires painstakingly specing every feature, effectively converting innovation into execution. More often than not, this stifles creativity and forces predictability over impact. I’d argue that we should usually prioritize impact when innovating.
When the industry standard is applied to innovation work, everything falls apart. Since product doesn’t know exactly what they want and engineering isn’t quite sure how to get there, those estimates are mostly fiction. Missed deadlines, stressed teams, and frustrated executives asking, “how do we avoid this next time?” Sound familiar?
This recurring failure highlights a deeper issue: the reliance on fixed scope methodologies. Unless work is truly execution, or can be spiked enough to get sufficiently close, all the estimation workarounds are just symptoms of a deeper problem.
The Fallacy of Fixed Scope
A fixed scope process defines how to do the work before you do it. The problem lies in the assumption that we know everything before doing the work. What hubris!
Nobody can predict the future, especially in innovation work where uncertainty is the norm. That’s why we work in “sprints”; to adapt as we go, tweaking the direction with each iteration. But these tweaks are usually variants on the same general direction, the same fixed scope. It’s quite rare that a team embarks on a multi-month epic and has the fortitude to admit they’re on the wrong path.
This is why agile often devolves into “agilefall”. In theory, pivoting every two weeks sounds great, but political, technical, and psychological barriers often get in the way. Teams face resistance to changing roadmaps, the pain of undoing recent work, and the burden of sunk cost fallacies, shame, and overconfidence. It leaves them struggling to chart the path forward.
The issue compounds when influential stakeholders — executives, product managers, engineers, and business partners — cling to their own idea of “done”. This rigidity drags out timelines and stalls delivery until all expectations are met.
At its worst, fixed scope feels prescriptive and strips intelligent engineers of their creativity. Product dictates the solution, and engineering is expected to follow orders, leaving little room to challenge assumptions. Even when some engineers are included early in the planning process, involving the entire team is often impractical. A healthy process empowers all engineers to critically evaluate product decisions and push back when needed, fostering collaboration and driving better outcomes.
So, how do we overcome these obstacles and achieve true agility for maximum impact? The solution is to adopt fixed timelines with variable scope.
The Case for Fixed Timelines
If everyone humbly acknowledges that we don’t know precisely what we want to build and commit to exploring our way into a solution, then we can more readily leverage other approaches.
A fixed timeline process involves specifying a maximum timeframe for a project, like four weeks, and allowing the scope to vary within that period. It ensures teams spend no more than four weeks on a project, while keeping the outputs flexible.
“The enemy of art is the absence of limitations.” — Orson Welles
Fixed timelines flip the script. Instead of asking, “how long will X take?” project planners reframe the question to, “how much time are we willing to invest in X?” This shift sparks collaboration, creativity, and ruthless prioritization by challenging the implementation team to deliver the best possible version of X within the allotted timeframe.
Innovation work inherently risks runaway scope, but time-boxing effectively contains it. Instead of eliminating ambiguity upfront — with spikes or exhaustive planning — fixed timelines embrace it, ensuring teams can adapt within clear boundaries.
I first discovered this approach in the Shape Up book. It offers many valuable insights, but the most salient takeaway is the concept of a fixed timeline.
Over the years, I’ve leveraged this framework for innovation projects with measured success. I’ve adapted the book’s principles to handle the complexity of healthcare, streamline processes, and maximize collaboration. I’ve shipped major overhauls to core infrastructure, launched brand new products, and built complex integrations. All on a fixed timeline. The result? Happier teams, better outcomes, and improved operational efficiency.
Benefits
When used appropriately, this paradigm has many benefits. In Part Three, I’ll expound on the benefits and the challenges. Here’s a snapshot of the upside:
- For product managers: Roadmaps become easier to plan with timelines fixed to a pre-defined length, reducing the need for day-to-day project management and freeing time for upstream activities like market discovery.
- For engineering managers: Teams become more collaborative because everyone knows what success looks like and discusses tradeoffs about the best use of their time.
- For engineers: Engineers want to solve business problems, not just implement prescribed solutions. Empowering them to get creative leads to greater fulfillment and better results.
- For senior leaders: Leaders gain more control over roadmaps by defining project length themselves rather than relying on engineering estimates.
- For executives: Executives spend less time worrying about project minutiae (the “how”) and more time articulating the vision (the “why”).
- For everyone: Power and influence over project completion shift to the people best equipped to deliver measurable outcomes: the implementation team.
In Part Two: I’ll show you exactly how to design fixed-timeline projects for success and transform your team’s approach to innovation. Follow on LinkedIn for updates!