“You can look at a problem, and either go ‘oh, this is a problem, or you can, KABOOM! Blow it up and turn it into something great! You literally KABOOM the problem.”
Besides being one of the funnier episodes of Parks and Recreation in recent memory (this scene alone has several classic lines), the Kaboom philosophy* is actually kind of fun to live by. We started using it (or perhaps overusing it – at least as a part of speech) at BrainBoost Education not that long ago. Of course, literally kabooming problems makes little sense (though it’s fun to say), but the practical aspect of kabooming as we decoded it – that is, not getting too hung up on details early on a project, not allowing the role of Devil’s Advocate to take hold, and trying stuff with a view to iterate quickly – all of that is, in many ways, great management philosophy.
If you wanted to test out a new layout for some physical space in the office, you would discuss it briefly, get approval (usually to applause), go off and kaboom it and then get feedback. For bigger projects, we didn’t stick to the one day timeline as it was often too restrictive, but if something had in the past taken months to do we were pretty sure we could kaboom it in a week or two (like our website). Again, getting it right the first time is less important than getting it finished. Perfectionists will find this a difficult trade-off to swallow; after all, there is always something you can improve – many perfectionists would prefer it if a project was never ‘done’. The simple solution is that nothing is ever truly ‘done’ – any end state is a subjective assessment that generally comes about when either a) further inputs to the project return marginal and/or diminishing gains, or b) there are other projects that will deliver sufficient ROI.
For example, it’s easy to finish a web design, get your site ready to go, only to postpone going live because you are gathering more data. You can gather information forever, but as noted by Nielsen, you really only need a handful of users to test it before you’ve found all of the important problems.
Of course, as noted in Nielsen’s findings:
The most striking truth of the curve is that zero users give zero insights.
So clearly, this project is not suffering from inputs that produce diminishing gains. It is not kaboomed.
First and foremost, kabooming is not about being careless. By all means, do some testing, allow some time for reflection, but get your web design or whatever project moved quickly to ‘done’. Kabooming is about optimizing to two constraints: time and completion. The interesting thing here is that time and completion trade off against one another. Completion is defined as the sum of a set of states that represent different features, actions or tasks. The more features that make up a project, generally the more actions and tasks are required to bring those features about, and in general, the more time this requires. The upshot of all of this is that setting up the scope of the project requires kabooming itself. It generally goes (or should go) something like this:
D: If we do that, then we need to redesign the website, and that’s a big task.
M: No it’s not – we can kaboom it.
D: Do you really think so?
M: We’ll literally kaboom it.
D: OK, what are the minimum requirements?
M: X Y and Z.
D: I think that will take one month.
M: Then cut Z.
D: Two weeks it is. Kaboom.
As the project rolls along, generally two phenomena will occur. The first is a reluctance to stay committed to the deadline as you realize you can’t make it. You will try to move the date backward. If you have a manager that understands kabooming, they’ll hold your feet to the fire and remind you that because it’s a kaboom project the only thing you absolutely have to do is ship on time. This second thing is that this generally leads to great spikes of productivity individually and as a team, particularly as the deadline draws near. You make the deadline either with all the features or without, but that’s the end of that cycle of production and the project has been officially kaboomed. Whether it needs another cycle of kaboom with the same team, a different team, or no team (there are more productive projects available) is up to the project owners. Generally, if all features have been completed, some small subset of the team will set about refining the project, but the engine will roll on to the next big thing that needs kabooming.
“Remember: take a man kabooming, he kabooms for a day. But you teach a man how to kaboom…kaboom, kaboom, KABOOM!”
Kabooming is addictive and I’ve adopted it to suit many of my own projects. I think part of the attraction is that when you commit to kabooming something there are two positive feedback mechanisms: first, you will experience a sense of blissful productivity as you knock items off the feature, task and action list; second, no matter the results, you get a strong sense of accomplishment even when the final result is unpolished. There is no better example of a kaboomed project than this website/blog. When I set out to get this website rolling, I began thinking about all the little obstacles that were in my way. I would have to decide on a domain name, a provider, a hosting service, a blog title, a layout, whether to use a CMS, – and quickly I would feel overwhelmed and rather than begin I would try to do something else. However, when I decided the project was kaboomable, I gave myself a four-hour window to finish the project. It wasn’t polished at the end, but the deadline forced me to make all kinds of decisions rapidly and I was proud of the output. Now that it exists I can devote smaller increments of time to its upkeep and optimization.
* Despite what happens later in the episode, KaBOOM is actually a real thing and they really do build parks for kids (though I’m not sure if they do it in a day).