The operating model for the AI era.
ZeroBlockers
Turn faster delivery into better outcomes.
AI makes software faster to build. Explore how to change ownership, decisions, funding and support so small teams can deliver what customers really need.
Explore the editions ↓The archive
Ideas for your next step.
A Product is not the Sum of its Parts
The assembly line was a simple but effective idea: complex products could be broken down into their smallest components, each optimised independently for maximum efficiency. This approach was based on the work of Frederick Taylor's book, The Principles of Scientific Management. T
Read edition ↗
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
Read edition ↗
Increasing Development Efficiency
The first step in improving efficiency is to agree what we mean by development efficiency because there are at least three, and possibly many more, ways that companies measure efficiency today.
Read edition ↗
Evolutionary Architecture: Because Change is the Only Guarantee
Bjarte Bogsnes, former CFO of Statoil, talked about the beauty of a perfectly balanced budget. But the feeling would only last for a fleeting amount of time because inevitably real world changes would mess up the perfect balance in the budget. The same is true of software archite
Read edition ↗
Rethinking Software Estimation: From Outputs to Outcomes
Estimation, or more accurately guesstimation, is a backbone of traditional project delivery. From executives seeking budget approval to development teams planning their sprints, we constantly make predictions about time, effort, and cost. It's easy to understand why - businesses
Read edition ↗
Every Feature Can Be Broken Down into Separate Releases
When proposing to break down a feature into smaller increments, the resistance often stems from a deeply ingrained belief: the feature will only work if all the requirements are in place. You’ve spent a lot of time understanding what customers want and designing prototypes to val
Read edition ↗
How to Decide Where to Focus your Engineering Efforts (using Wardley Mapping)
“Yes, there are products that deliver some of the functionality we need for our feature, but those products are overkill; we only need a fraction of the functionality. By the time we integrate with the other product, we could have built it all ourselves.”
Read edition ↗
Breaking a Complex Solution into Multiple Releases using User Story Mapping
Imagine you’re working on a team and you get a requirement to add a new expense tracking feature. The prototype has received rave reviews and the internal teams are really excited to start saving time on the monotonous receipt submission process. However, there is a significant c
Read edition ↗
Managing Test Case Explosion with Feature Flags: Strategies and Solutions
When a system implements feature flags, each flag doubles the number of possible states the system can be in. One feature flag results in two different paths but with just 10 feature flags, there are theoretically 2¹⁰ (1,024) different combinations to test. Testing each configura
Read edition ↗
DevOps: A Cultural Change, Not a Technical Revolution
Before DevOps, development teams often operated in isolation from QA and operations. Each group had its own goals:
Read edition ↗
The Real Cost of Changing Designs
Duke Nukem Forever took over 14 years to develop due to a string of requirements changes, scope creep and unforeseen challenges. Originally announced in 1997 as the highly anticipated follow-up to the wildly successful Duke Nukem 3D, things didn’t go according to plan. The team w
Read edition ↗
The Hidden Costs of Big Design Up Front (And How to Avoid Them)
The software delivery lifecycle includes six key stages: plan, analyse, design, build, test, and deploy. Whether you are following the Waterfall or Agile methodology, you will need to go through these stages but the difference lies in the size of the work you do in each stage. In
Read edition ↗
When is Enough, Enough? Or When Do You Stop Testing and Start Building?
One of the most challenging decisions teams face is determining when to transition from testing designs to actual development. In reality this decision is fairly straightforward. The problem is that our organisation structures and processes have made it complicated.
Read edition ↗