The Inefficiency Crisis in Software Development

In 2009, Ronny Kohavi, then a leading data scientist at Microsoft, analysed the effectiveness of product experiments across various teams. His findings were stark: 33% of features had no measurable impact, and another 33% actually made the product worse. That means two-thirds of all product ideas failed or had negative consequences.

More recently, while working with Airbnb and Netflix, Kohavi observed that success rates had dropped even further—to just 8-10%. This aligns with broader success rates of technology startups, where failure is the norm rather than the exception.

Companies aren't just wasting resources on ineffective features – they're actively harming their products most of the time. Each new feature adds complexity, increases maintenance costs, and often degrades the user experience. Yet despite this evidence, the drive to add features continues unabated.

Why Software Development Is So Ineffective

Many organisations make product decisions based on intuition, opinions, or gut feeling rather than rigorous data. This leads to what’s known as the HiPPO effect—decisions made by the Highest Paid Person's Opinion, rather than those based on real-world evidence.

Even in companies that embrace some upfront research, ideas are locked in at a business case stage. Upfront research can reduce the risk of building the wrong thing, but it doesn't guarantee success. The real world is unpredictable, and the only way to know if a feature will work is to test it in the wild.

By the time it comes to evaluating whether a feature was successful, nobody is really interested. The team are happy they got the feature into production, the sponsors have moved on to the next big idea, and the users are left to deal with the consequences.

Without a mechanism for learning from failures, teams keep building things that don’t matter, wasting time, money, and engineering effort.

The False Promise of Agile

Agile methodologies were meant to increase adaptability and responsiveness. However, in many companies, the existing processes and culture limit what can actually be implemented, resulting in Water-Scrum-Fall implementations.

What was supposed to be about delivering outcomes through small iterations has just become another project management technique to deliver more features faster.

How We Can Improve Outcomes

The first step in recovery is always to first admit you have a problem. Once you accept that most features fail, and you can visualise the amount of money, and opportunity, being wasted, you can start to make changes. The challenge is that shifting from outputs to outcomes requires changes at every level of the organisation:

1. Process

Instead of asking teams to build a specific feature, ask them to solve a problem. This changes how teams work - instead of building a spec that has been handed to them, they need to research the market, identify opportunities and then build them.

2. Alignment

How do you ensure that teams prioritise the right problems if you are trusting them to deliver outcomes? This requires a clear vision and strategy that is understood by everyone and then tactics to monitor whether teams are following the strategy.

3. Structure

How do you organise teams, particularly if they are autonomous and can choose what to work on? There is a massive risk of teams unintentionally duplicating effort.

4. Funding

How big should each team be when you don't have clarity on the features they will be building or the ROI? While the ROI calculations were fictitious, it gave finance teams more confidence that the alternative of “trusting” teams to do their best.

5. Governance

With a defined scope with clear time and cost constraints, how do you ensure that teams are delivering value? This requires a shift from project management to product management.

6. Scaling

Strategies that might work on a single team need to be able to scale across the organisation. This requires a view on additional supporting teams like Enabling teams and Internal Product teams.

This is the challenge that led to the creation of ZeroBlockers. Without clear guidance every company that wanted to go down this path needed to reinvent the wheel. However, there are some companies that have successfully made the shift. ZeroBlockers has codified the best practices from these companies into a set of tools, templates, and training that helps companies make the shift from outputs to outcomes. It is a way to help companies avoid the pitfalls that have plagued so many others.

Conclusion

The inefficiency crisis in software development is real. Most product features fail, and many actively harm users. The reason? We lock in assumptions about what customers want and focus on delivery instead of validating these assumptions.

The solution is to shift from outputs to outcomes. This requires changes at every level of the organisation, from process to governance. ZeroBlockers provides a roadmap for companies to make this shift, helping them avoid the pitfalls that have plagued so many others. The result is a more efficient, effective, and user-focused product development process that delivers real value to customers.

If you want to start on this journey check out our courses covering all aspects of the change journey.