Build, then iterate? Or iterate then build?
Anthony Sean McSharry
Problem Solver, UX Leader, Speaker, Mentor/Trainer. Researcher, Service Designer, Product and management Consultant. Author and Actually Autistic...phew
"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
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
领英推è
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
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
Designing for AI-powered platform experiences at ServiceNow
1 å¹´I really needed to have someone say this. This is a major gripe I've had all along. I think it's lazy not to try to establish your POV through research, data, etc., but instead build stuff, put it in the hands of users, and see if they like it or not.
Head of Prospective Student Web at The University of Edinburgh
1 年Great post. Sadly all to familiar. In the HE sector it’s less about the rush to beat competitors in the market, and more about delivering in a window in the academic cycle which if you miss, means waiting another year.
Helping digital teams and full-service agencies uncover actionable insights through research | Providing the bolt-on freelance skills and capacity you need to build great products.
1 å¹´Many truths in this piece. I started as a product designer, not the digital type the title is used for now, but designing and developing real electronic physical products. Tooling and manufacturing needs meant a largely waterfall approach. When I moved over to full digital design and agile development I was always perplexed by the pressure to ship. The features could slip, the scope could slip, quality could slip but rarely the release plan dates. Much success for a product is in timing BUT also in first impressions of early users and the related adoption rates. I never, and still do not understand the concept of MVP in practice, because through so many releases working with so many teams, I've seen so many things launched that are just not viable.