Shipping isn’t the win

Shipping to production used to be the win. But that’s exactly why we couldn’t let go of things that didn’t work.

The traditional way of developing software within enterprises has been to spend a lot of time justifying a project by creating imaginary business cases and cost evaluations. Then it takes months to build the thing, only to discover that it doesn’t provide any actual value.

At this point the sunk cost fallacy sets in, and we try to save the effort we already spent by adding “change management” or building just one more feature, and end up banging our heads against the wall even harder.

I’ve made this mistake myself as well. We had a great idea for a solution. I fought through the corporate jungle to secure a budget, team and buy-in. We spent 5 months building it until we shipped to production. Initial hoorays for the achievement: we actually shipped something! Then we started looking at the daily user volumes and calculating the impact on business. Cold sweat. Maybe just one more feature will make a difference.

Well, it didn’t. Letting go was extremely difficult: we had put all that time and effort into a solution we actually managed to build, and the most important thing was still missing. Value.

With AI-assisted development, going from an idea to a working prototype can take hours instead of months. This opens the door to working in a more value-centric way, even for enterprises. That means quickly building something you can put in front of users to discover whether the value potential is actually there.

But we need to be careful, because it can be very tempting to just build things.

As Karri Saarinen recently wrote in his essay “Our organizations are being DDoSed from the inside”, we need to get past treating output as proof of value. A working implementation shows that something can be built, not that it belongs or creates value.

To take advantage of faster software development, a team needs to decide before building which results would justify keeping the thing, and then actually be able to shut it down if it doesn’t reach those results.

In my experience, shutting down an experiment is easier when you explore several solutions at once. They can be different solutions to the same problem or solutions to different problems. When I led a recommender system team, we always aimed to run a bunch of experiments at the same time, because we had learned that even a strong value hypothesis doesn’t guarantee results in the real world. This turned “admit failure” into “choose which one to continue”, and nobody lost credibility. When a team builds only one solution, shutting it down means someone was wrong.