Software can be changed quickly. High performing teams can ship a new release to end users multiple times per day.
When we realise this and make use of it, we can push against the problems of perfection, of doing nothing or endlessly refining plans. Instead, we can slice up changes to be small, to be good enough to take the next step and to be quick to revert if they weren’t actually what we wanted.
The thing that unlocks these behaviours most quickly is building in the deep understanding that something that is out in the world providing value is better than the most perfect system that’s still stuck on your private network.
It’s hard to do, as you need to get used to things not being the absolute best they can be, instead that they are good enough to solve a problem today and can be improved tomorrow.
The best way I’ve found to break the desire for perfection is to connect directly with your end users. Every layer between you and the person using your solution is an extra chance to focus on something other than shipping the change, so cut through them to go faster.
When you meet up with users and see their daily pains, shipping something now that solves some of them is always more appealing than shipping something in a couple of months that might solve all their pains.
You also get fast feedback on the things you’ve already given them. You find out what’s really important to them, and also which of the details you sweat over they really care about.
Fast feedback loops like this encourage you to go faster. Ship small incremental changes when they are ready rather than building up big blocks that will be ‘perfect’ from day 1 but never actually going anywhere.
Unshipped changes are worth nothing. Get them in front of users and iterate, and capture that value now!