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 validate a solution that works for them. Removing some of the elements now will render the feature useless.

This all-or-nothing mindset can lead to lengthy development cycles, increased risk, and missed opportunities for early user feedback. When the theory of evolution was first being proposed, it encountered similar objections: some parts of the anatomy only function in their completed form. How could things evolve when half an eye cannot see and half a wing cannot fly.

Evolutionary Arguments

One of the arguments against evolution was what is known as Irreducible Complexity. But biologists have been able to refute all of the examples because the animal kingdom contains examples of species that are gaining value from iterations of increasingly complex eyes and wings.

The Evolution of the Eye

Eyes evolved in stages, starting as simple light-sensitive cells. Even these rudimentary structures provided significant survival advantages, such as detecting day from night or sensing movement. Each incremental improvement – from forming basic lenses to evolving more sophisticated optics – built upon this foundation, demonstrating that “half an eye” was not only useful but critical for survival.

The Evolution of the Wing

Similarly, wings didn’t emerge fully formed. There are many animals that have webbed arms to aid in gliding between trees, regulating body temperature, or attracting mates. These partial adaptations provided value long before true flight evolved.

The lesson for product development is that even a feature in its early stages can provide value to specific customer segments or contexts. You just need to find a subset of users who can get the most value out of even rudimentary solutions.

Other Objections to Breaking Down Complex Solutions

Process Objections

If you are working in what I call “Business Case Driven Development”, iterative development can be seen as a negative. The business case has already defined the scope, as well as the budget, so why risk getting feedback that might result in changes? That’s scope creep! The changes might improve the product but the KPIs are not based on the effectiveness of the product, they are based on the predictability against the business case budget.

The other big process objection is that multiple releases cost more than a single release. But the build cost is only one of the costs associated with software. Holding costs include the revenue that teams failed to earn or the costs they failed to save because a feature was not released. If the feature is valuable, even an early version can provide revenue and/or costs savings. And that’s before we even get into the maintenance costs of supporting overly complex features for the life of our product.

Structure Objections

If software is delivered by creating a project team of different functional experts then there will be a tendency to break up the solution into functional components. This is like building a bridge in segments. The bridge is not functional until every segment is completed. Instead we need to break up our designs in a different way - a technique amusingly called Elephant Carpaccio. We need to create completely functional slices of our product. Using our bridge example it would be the equivalent of building the bridge lane by lane so that it was functional from the first release. Luckily software is a lot easier to change than physical bridges!

Industry Objections

Another common objection, particularly in finance and healthcare companies, is that compliance or safety standards necessitate a “complete” implementation. And yet there are companies that are succeeding in those industries by releasing fast and often. Digital banks are taking market share away from traditional banks and companies like Qualio are moving rapidly in the healthcare space by embracing agility and continuous delivery practices.

How to Break Down Features Effectively

Breaking down solutions requires identifying the core customer need and delivering value iteratively. Using your research to drive the conversations you can use tools like User Story Mapping and Wardley Maps to agree on the best ways to split your releases.

I have included examples of how to break down a solution in the articles linked above so I won’t repeat them here. I recommend reading the articles if you want to get more hands-on with real world examples.

Conclusion: It Can Be Done

The belief that a feature must be delivered in its entirety to work is as flawed as the argument that “half an eye” or “half a wing” is useless. Just as evolution demonstrates the power of incremental progress, you can improve the quality of your products by breaking down features into manageable, value-driven increments.

By understanding customer needs, targeting specific segments, delivering end-to-end slices, and testing assumptions early, teams can overcome resistance and unlock the potential of iterative development. The next time someone insists a feature is “all or nothing,” remember: every feature can be broken down – and doing so might just be the key to its success.