Build, then iterate? Or iterate then build?

"I was flying the plane while I was building it"

I came across this inspirational quote today. It speaks to the nature of our ability to overcome adversity and seemingly impossible challenges. People have spirit, determination and skills...and they're all being wasted because some idiot launched the plane before it was finished being built, putting the organisation's reputation and the 'paying' customers at risk. That approach is bad for everyone, but the product owner or stakeholder believes they've delivered a win by delivering quickly and sadly it's become a cultural norm.

There was another quote next to it. What it lacked in inspiration it made up for in the reality :

"The time to worry about flying is when you're on the ground. When you're up in the air it's too late. No point in worrying about it then"

These speak, relatively, to the attitude we see in 99% of projects and the reality of the futility/cost of trying to iterate a product that was built, or worse, launched before it was ready.

Why we build, launch and then iterate

The argument that "we need to be first to market" is long since refuted. None of the most successful companies or products were first to market (despite urban legends to the contrary) - they built on the failures of those who were first, and then they became "first to market something that actually worked". They just seem first to market because they're the first one we remember...because they didn't go out of business.

Apathy, incompetence and a sheep-like mindset all have their part to play too. We work in a culture that embraces group think, resists change and aggressively defends 'the way we've always done it'. And integrity, whilst spoken of loudly, is viewed with silent contempt when the wheels actually hit the road.

Adversity makes our achievements feel bigger, greater and more worthy, so we focus on the team work and adversity, not the failure. We celebrate making it through the storm and ignore the fact we landed on a desolate island inhabited by cannibals. But it's a classic false economy - we're making something that could be straight forward much harder than it needs to be and then celebrating the rush of achievement over something that's actually quite achievable if we'd done it the right way in the first place. It costs more and achieves less in every way.

If we iterated (research, prototype and test) until the solution was ready to be built we'd not only launch much more successful products and spend less money doing it, but our brand reputation and value would rise commensurately, and, we'd have the time, skill and determination to take on bigger, better, more valuable challenges, that truly would provide us with worthy adversity, a few celebrity level dinner party failure stories and many commendable successes.

Take Away

Fixing the plane while it's flying is not aspirational. It's wasteful, dangerous, costly and fraught with incompetence. No one in their right mind would do it. Iterating through the problems and improvements of a product after it's built or launched is no different and it just pisses off the passengers.

Those who are brainwashed to this process will aggressively defend "the way we've always done it" without thought or consideration. There will be glib soundbites like "We haven't got time for research ", "we just need to get something out there", "the client keeps changing their mind", "we are being agile" or claims that we are running out of time/money etc, but these are mindless standard responses to the symptoms of the root cause, not to the cause itself.

Iterate (and test) until you're ready to build. Then you can celebrate how much you achieved. If you do it the other way round (build then iterate), even without launching it, you stand to waste a lot of time and money on the build process (before you run out of both and just 'have to deliver something'). All you'll have to celebrate is how hard you all worked.

'The way we've always done it' is invariably and excuse to avoid the existential pain of change and the fear of failure from the unknown.

Another common problem I see if building and launching something that your users will iterate for you, through its failures. Those users are your paying customers and 'when you're up in the air it's too late'. If they survive the experience a lot of them won't be coming back. Sky TV's unsubscribe process: I'm looking at you.

It doesn't cost more to do proper research - it costs more to not do research. It only feels like it's delaying the launch, but it's not. Research makes and saves a LOT of money that cannot be gained anywhere else. Launching a half built plane isn't launching - it's throwing your garbage at your paying customers, with tangible contempt for their needs and welfare - AND THEY KNOW IT, no matter how much of a dog and pony show marketing put on.

Your competitors won't beat you to the punch in any meaningful way (or at all), when they launch something they haven't tested and iterated - their solutions will crash, burning, to the ground with their customers on board. Very sadly Boeing demonstrated this literally recently, for all the reasons above. This never needed to happen.

Research - hypothesise - prototype - test and iterate, until you know you are ready to build a valuable, successful thing. Sounds obvious but look around and see how often it actually works that way - I'd be surprised if anyone reading this could say "my company does it the right way".

Basically, if you want to avoid financial, reputational and functional debt, iterate then build, not build then iterate. But if you're reading this you probably already knew that.

#functional-architecture #functionalConsulting #ux #uxsanctuary #uxresearch