Steve Jobs – It's the 80% You DON'T Build That Boosts Your Output

• Most digital projects can deliver with 20% of the budget if we discard the 80% of low-value bits that don't directly contribute to the business outcome.

• I'll share a compelling Steve Jobs video that illustrates this and discuss some real-world examples of my own where I've compared before-and-after budgets.

Constantly challenging what we include makes sense for hardware—why not digital?

When you're creating something physical, like a computer, it's obvious that the final product represents only a small subset of the ideas considered and even engineered before many are discarded. There's only so much you can realistically fit, both physically and financially. Of course, you have to leave things out.

The same principle applies to digital solutions, including the systems and features we build to deliver joined-up user experiences, reduce administrative burdens, or improve customer services.

This may sound counterintuitive, but in my experience, it’s consistently true:

20% of the budget can deliver the desired outcome—IF we clearly measure the value of each proposed feature.

This may cause a visceral reaction among IT professionals (including me 😬), but hear me out.

The "we need to build everything" misconception is deeply rooted

The belief that we must build everything "in scope" to deliver the promised business benefit is sustained by inertia—decades of inherited practice from traditional project management (waterfall) and even agile methods. Both methodologies lack a robust mechanism for refusing unnecessary features.

Without a clear way to measure value, there's no effective rationale for rejecting requests or prioritising high-value features. Often, we end up delivering low-value features first, leading to budget overruns.

No wonder projects frequently exceed budgets

Typically, projects go over budget because "the business" throws in every request without justification for why it's essential. Phrases like "the business asked for it" become a trump card, and internal teams often just accept the added work without questioning its actual benefit.

Steve Jobs on eliminating the 80%

A recent 1-minute video of Steve Jobs expresses this brilliantly:

Jobs emphasises success by eliminating unnecessary code, not just writing code faster.

The "other way" happens regularly—it's just not mainstream

Since 2010, I've successfully delivered 250+ projects by applying this exact philosophy. Many were new projects, but several were rescues that allowed direct comparison between original budgets and what we actually spent. Here are a few examples:

Central to these successes was continuously asking users—not managers—which elements directly supported business outcomes. We stopped building when we reached diminishing returns. Users quickly embraced this approach, often challenging developers rather than vice versa.

Importantly, users weren't tasked with providing "requirements," but simply describing their problems. Our responsibility was to interpret their problems, prioritise by value, and deliver practical solutions.

Example 1: Call Centre Redevelopment

An 18-month project delivered a highly successful call centre experience to 2,500 agents across four call centres, resulting in over $20m annually in measurable benefits. This project had previously failed repeatedly over ten years, with estimates to deliver the software alone at $40m. We completed it successfully for just $4m—a 90% budget reduction.

Example 2: POS Redevelopment

We stepped into a troubled £70m POS redevelopment for a major UK retailer after two previous failures, with £10m already wasted. Initially budgeted at £35m for software alone, we successfully restarted and completed it over 24 months, deploying the first working version within three months. Our solution cost slightly over $5m, saving between 85% to 89%.

Example 3: Digital Media Self-Service

Initially proposed at $15m and repeatedly unfunded due to high risk, we restructured the project into a $1.9m, 12-month delivery with 90% funding contingent on early success. We delivered an initial version in two months for $150k, gained confidence and funding, and ultimately came in under budget. Stakeholders approved using remaining funds for another opportunity we identified—achieving even greater business value.

Conclusion

The key takeaway is simple: Projects can be dramatically more cost-effective if we continuously evaluate the real value of what's being built.

Implementing this evaluation method requires far less training than adopting agile practices, and both teams and users find it intuitive.

Once this approach is in place, each step involves building only the next most valuable feature. Projects end when the budget runs out or sooner, once diminishing returns are evident.

Example 3 was my first application of this approach, followed by over 250 more successful projects. Even teams new to this method can deliver remarkable business outcomes.

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.