Despite not having seen him for perhaps 20 years, I continue to learn from Paul Earwicker.

One thing that still resonates with me was his advice on design. Say you were tasked with producing the lightest possible bike frame that wouldn’t fail under normal use, but had no access to modelling tools. How should you proceed?

You could design a frame that was obviously strong enough, but how then would you know how much material you could remove to make it light enough? And where would you remove it from? No, faced with this challenge the rational approach (provided you don’t value your front teeth) is to make a frame that is not strong enough, and ride it. When it breaks, reinforce the places where it broke. Repeat until it doesn’t break, and you will have a minimal frame.

When it comes to software, I’m working to deliver a Minimal Viable Product. But my customers and I are constantly disagreeing on whether a feature or enhancement is in or out of the minimal set. They want to add things, I want to deliver what we have. Why? Because as with the bike frame, it’s easy to know minimal when you see it, but hard to predict what makes a thing viable. If you actually want to ship an MVP, you have to approach it from below, delivering a product that turns out not to be viable and adding to it until it is. You have to look back and say, ah, that minimal release was the first one that was viable.

Why are my customers fighting this? Well they’re rational too, and know that a consequence of this process is that your first few releases will be failures. If you can’t survive the embarrassment of walking home with a broken bike frame, then maybe it’s best to make sure that your MVP process is a bit less public.