The Clean Up Sprint

Ever been in a situation where a project is stuck in an endless loop of polish?

‘This styling is wrong’ the QA says.

‘We can’t release’ says the PM.

‘But’, you say, ‘if we launch this now, we can start gathering data to see if this feature even has legs and we can then plan the subsequent course of action’.

Founder steps in and says that one of his friends was using the product and sent a screenshot where the product was not looking nice and it was very embarrassing for him so yeah, it has to be perfect when it ships.

‘Can’t we clean it up later?’ someone asks.

‘Theoretically yes’, says the PM, ‘but that never happens.’

Conundrum.

You, as the CTO, know that the the entire issue with styling is tiny compared to the cost of delay in launching. As bad as the styles look, the launch of the feature delivers real value to users and makes the product better. Launching now enables the learning and feedback loops to start operating. Devs have been working on this for weeks and are frustrated about the delay in launching. There is a very real cost of delay.

the cost of delay

Most product orgs do not have a visceral sense of the cost of delay. Delays compound fast. The difference between running two experiments and three experiments in any given time period adds up tremendously. Most feature launches go nowhere. At best they provide incremental gains. But occasionally you get a ‘hit’ and no one really can predict, despite all user interviews and research, what is going to be a hit. Anyone who tells you beforehand what is going to be a hit is lying. If they were that good…..

Let’s say that one in ten feature launches really moves the needle and changes the trajectory of the company. The most reliable way of getting more hits is to ship more experiments and learn more about what users are really lapping up. And the difference between getting your hits every six months versus every nine months is a massive drag on the orgs trajectory.

What to do? I solved this by instituting ‘clean-up sprints’.