The Budget-First Revolution: What Most Product Development Teams Don’t Know

In the world of product development, there are two fundamental approaches to budgeting: the cost-first approach (“How much will it cost?”) and the budget-first approach (“What can we get for our notional budget limit?”). Despite these being equally valid options, most organisations default to cost-first estimation simply because they’re unaware that budget-first is a legitimate alternative. This unconscious limitation of choice often leads teams down a path of unnecessary estimation complexity when a simpler approach might better serve their needs.

The Cost-First Approach: The Traditional Path and Its Pitfalls

The cost-first approach begins with a vision of what needs to be built and works backwards to determine the necessary budget. Whilst familiar to many organisations, this traditional estimation-based method comes with significant challenges and drawbacks:

The Estimation Fallacy

Studies consistently show that development estimates are notoriously inaccurate. The Cone of Uncertainty suggests that initial estimates can be off by a factor of 4x – or more – in either direction. Even with experienced teams, complex projects routinely exceed their estimated budgets by 50% or more.

Hidden Costs of Estimation

The process of creating detailed estimates consumes significant time and resources. Teams often spend weeks in estimation meetings, agreeing requirements, preparing documentation, and defending their numbers – time that could be spent actually building and delivering value.

The Planning Fallacy

Humans consistently display optimism bias in planning, underestimating the time and effort required for complex tasks. This psychological tendency, combined with pressure to provide “acceptable” estimates, leads to systematic underestimation.

Requirements Instability

The cost-first approach assumes requirements can be accurately defined upfront. In reality, requirements often change significantly during development as understanding evolves and market conditions shift. This makes initial estimates increasingly irrelevant as the project progresses.

Perverse Incentives

When estimates become commitments, teams face pressure to cut corners to meet arbitrary deadlines. This can lead to technical debt, reduced quality, and increased long-term costs. Additionally, teams may pad estimates defensively, reducing trust and transparency.

The #NoEstimates Movement

In response to these challenges, the #NoEstimates movement has emerged as a critique of traditional estimation practices. Pioneered by practitioners like Woody Zuill and Neil Killick, the movement questions the value of detailed upfront estimation in product development.

Core Principles of #NoEstimates:

• Focus on delivering small, valuable increments rather than predicting future costs
• Use historical data and throughput metrics instead of speculative estimates
• Make decisions based on value and capacity rather than detailed predictions
• Embrace uncertainty and adaptation rather than trying to eliminate them through planning

Alternative Metrics

Instead of detailed estimates, #NoEstimates advocates suggest focusing on:

• Cycle time: How long it takes to complete work items
• Throughput: How many items are completed per time period
• Value metrics: Direct measures of business impact
• Running tested features: Working software in production

The Budget-First Approach: Starting with Notional Limits

The budget-first approach flips the traditional model by starting with a notional budget limit and determining what can be delivered within those constraints. Whilst this approach has gained popularity with the rise of agile development and lean startup principles, it remains surprisingly underutilised. Many teams continue with tortuous estimation processes simply because they don’t realise they have a choice.

Understanding Notional Budget Limits

The term “notional budget limit” is crucial here – it represents the realistic financial boundaries within which the team must operate. This isn’t about arbitrary restrictions, but rather about acknowledging the actual financial constraints that exist in most organisations. These limits might come from:

• Annual departmental budgets
• Quarterly funding allocations
• Project portfolio constraints
• Market-driven price points for the final product

Working Within Known Constraints

Rather than spending time estimating costs that may or may not fit within available budgets, teams start with the known financial constraints and work backwards. This creates a more focused conversation about:

• What features provide the most value within the budget limit
• How to phase delivery to match funding cycles
• Where to make strategic trade-offs
• How to maximise return on the available investment

Prioritisation is Key

Rather than exhaustively documenting all possible features, teams focus on identifying and prioritising the most crucial functionality. This often leads to better-focused products that deliver core value more efficiently.

MVP Definition

Teams work backwards from the notional budget limit to define a Minimum Viable Product (MVP) that fits within financial constraints whilst delivering essential functionality. This forces tough but valuable conversations about what features are truly necessary versus nice-to-have.

Innovation Through Clear Constraints

Understanding the notional budget limit upfront often drives more creative solutions. Teams focus their innovation efforts within known parameters rather than generating ideas that may prove financially unfeasible.

Why Teams Don’t Choose Budget-First

Understanding why budget-first remains underutilised can help organisations make more conscious choices about their approach:

Cultural Inertia

Many organisations have deeply ingrained practices around estimation and budgeting that are rarely questioned. The very idea that there might be an alternative to detailed estimation often comes as a surprise.

Misunderstanding of Control

There’s a common misconception that detailed estimates provide more control over development outcomes. In reality, budget-first approaches often provide better control by forcing early decisions about priorities and trade-offs.

Fear of Commitment (Lack of Trust)

Some organisations avoid stating budgets upfront, believing it will lead to teams consuming the entire budget regardless of need. This fear often leads to the more wasteful practice of extensive estimation exercises.

Procurement and Governance Requirements

Many organisations believe their governance processes require detailed estimates. In reality, most governance requirements can be satisfied through budget-first approaches with appropriate documentation of assumptions and priorities.

Choosing the Right Approach

The choice between cost-first and budget-first approaches often depends on several factors:

When to Use Cost-First

• Regulatory compliance projects with non-negotiable requirements
• Mission-critical systems where functionality cannot be compromised
• Projects with well-understood requirements and clear technical paths
• Organisations with flexible budgets and focus on comprehensive solutions

When to Use Budget-First

• Startups and new product initiatives with limited funding
• Innovation projects where learning and adaptation are crucial
• Organisations with strict budget cycles or financial constraints
• Projects where time-to-market is a primary concern

Making the Choice Conscious

To move towards more effective budgeting approaches, organisations might choose to:

Question Default Practices

Before automatically responding to the question “How much will it cost?”, teams might choose to explicitly consider whether a budget-first approach might be more appropriate.

Educate Stakeholders

Help decision-makers understand that budget-first is a valid and often more effective approach. This includes explaining how it can lead to better outcomes and more efficient use of resources (i.e. lower costs, quicker time to market).

Start Small

Consider piloting budget-first approaches on smaller projects where the stakes are lower and resistance to change may be less intense.

Success Factors for All Approaches

Regardless of the chosen methodology, certain factors are crucial for success:

Clear Communication

All approaches require transparent communication about constraints, whether they’re financial or functional. All stakeholders may choose to understand and agree to the chosen approach and its implications.

Realistic Expectations

Teams may choose to be honest about what can be achieved, whether working within a fixed budget or estimating costs. Over-optimism in either approach leads to disappointed stakeholders and stressed teams.

Regular Review and Adjustment

All approaches benefit from regular checkpoints to assess progress, adjust plans, and ensure alignment with business objectives Cf. Tom Gilb’s Mountain Goat principle). This includes being willing to make tough decisions about scope, quality, or additional funding when necessary.

Conclusion

Whilst the cost-first approach remains common in many organisations, this is often due to habit rather than conscious choice. The emergence of budget-first thinking, which starts with notional budget limits, reflects a broader shift toward more adaptive, value-focused approaches to development.

The key is not just to choose between approaches, but to make that choice consciously rather than defaulting to traditional estimation methods out of habit. By acknowledging that working within notional budget limits is a valid starting point, organisations can make better choices about how they approach budgeting and delivery.

Success in modern development invites questioning of traditional practices and being willing to adopt approaches that might initially feel uncomfortable. Whether through budget-first methods, #NoEstimates practices, or hybrid approaches, organisations have more options than they often realise for moving beyond the limitations of traditional cost-first estimation.