Go/No Go
Deciding on whether we should or should not launch a feature is not only tough but there’s never a good vibe in those rooms. It’s usually a painful session where everyone’s anxieties converge and if we’re not careful, we end up paralysed, unable to make a call…or just as bad, deciding out of fear. The stakes are high when our expectations are high. A team has spent (probably too long) working on something and it is about to get crushing.
There’s a temptation to “know it all” and charge down an intoxicating path of ironing out all the ceases. It makes us feel better, gives us confidence, and we can feel in charge of things. Just a little more time to make it more perfect. Another month to deliver something truly exciting.
The truth is that it’s impossible to know whether we’ve done the right thing until it’s in the hands of users, out in the wild.
Tailors make the final fitting for a suit when it’s on the customer. We should do the same so we can build a product that fits.
There’s real humility in all great software teams. They know that they put their best foot forwards and that their best intentions can also be entirely wrong. They’re not afraid to learn, to discover where the gap lies, and to go back to the drawing board and try again with fresh insights and learnings. This is why they don’t waste time getting things out the door.
Building a culture of “progress over perfection” in software teams is essential. There will never be a perfect build, a perfect design, perfect data… something should always be left a little wanting. There should be an appetite to “ship to learn”. Always spend the least time you can to build something, and then with user input, assess and calibrate.
Set up a team culture and environment where you can (nearly) always Go.
- Be biased to launch
- Intentionally ship things that need a little more work
- Get to know the balance of “just enough”
- Build tolerance for risk and keeping checking in with that
