For the past few months, our product team have been working through the release of many sizeable new features. The steady release cadence lulled us into a seamless & effective rhythm for delivering great product. Until we hit a larger, more precarious release. With a higher risk-factor present, our routine methods for rolling out our new features didn’t seem to cut it anymore. I found myself questioning our framework for knowing how we should handle this larger, riskier release.
Lessons from 10,000 hours of popping popcorn & launching products.
Working through big feature releases can be daunting. You and your team have spent months battling tenaciously to find the right problem to solve and then working diligently towards designing the perfect solution. UX & engineering have worked in synchrony to build out an awesome new interface to address key pain points. Requirements have been captured, we’ve agonised over the perfect user experience, the UI has been meticulously crafted, and performant, semantic code has been committed. Now that we’ve built out all the features, we’ve also got several rounds of testing, polishing and bug-hunting to do before it gets out the gate.
We’ve tackled all these steps, but how will we know when we’re truly ready to launch?
Even when you’ve been able to keep a relatively good grasp on an achievable scope, it can be hard to know when to draw the line. There’ll always be design improvements, usability fixes, bugs to squash, supplementary functionality to add, ways to improve performance … the list goes on.
In the past month as our product team have been working through a few big product releases, we’ve been reflecting on these thoughts:
- How do we know when we are done?
- How do we know when to release?
- When do we announce our awesome new features?
- If we get stuck on getting a feature to 100% — Do we ship without it, or delay the release?
Getting close to a big release, there’s a certain energy in the air. Engineers want to know when they can draw the line and ship to production. Sales want to know when they can demo the new platform to existing and potential clients. Customer Success want to know when they’ll have to scale up to support the new part of the product. Marketing wants to know when they should be promoting the release.
The Popcorn method to shipping product
The Popcorn Method is a surprisingly simple but effective analogy I’ve been sharing with our team during these confusing times:
How do you know when the popcorn is done?
When the popping slows down.
When the popping slows down
When you put the popcorn in the microwave, at first there’s a small moment of silence, where you only hear the gentle hum of the microwave turntable. After 30 seconds or so, light popping sounds begin, followed by the thunderous pops of the majority of your kernels. Give it 20 seconds longer, and the thunder subsides to the occasional pop here & there. That’s how you know it’s ready to take out and enjoy.
The same is true when you’re getting ready to ship a sizeable piece of product. At first you’ll ask your teams to start putting your release candidate to the test, and a huge amount of popping will ensue. Upon those fateful first ventures into the new features, there’ll be bugs galore for your test group to discover.
After addressing many of the issues discovered, and once the popping slows down from your internal testing, you’ll summon up the courage to take it to the next level. Involving your users in your final testing process. Again, there may be pops galore in the first few days and weeks, followed by a noticeable deceleration. When the bug reports start coming in every few days instead of every few hours, you’ll be in a good position for a launch.
When you can smell the butter
When the popping starts to slow down, the delightful aroma of freshly popped popcorn fills the room, along with that faint scent of buttery goodness.
You’ll have confidence it’s a great release when your customers have validated that it’s an improvement to the product, and it has a positive impact on their workflow.
If your smaller test group of customers are enjoying the new feature set that you’ve built for them, you’ll be able to feel the energy & excitement buzzing out of them. You’ve just made their favourite product 5x better/faster/more powerful and possibly improved the enjoyment of their day-to-day job tasks. The strong customer validation will go a long way to increasing your confidence that you’re launch ready.
Other lessons from the Popcorn Manifesto
Serve before it goes cold
For all those times that a feature gets built almost to completion, and then put on the shelf to gather dust. 6 months goes by, and by the time we pull it back into a sprint and dust off the cobwebs to add the finishing touches, there’s a whole slew of new issues that we need to address before it can be released.
Keep the un-popped kernels in a jar for later
What about those last few features & enhancements that you just couldn’t get over the line? In order to avoid a delayed release, sometimes you’ll have to remove a feature or two that doesn’t quite make the quality cut. Even if features don’t make it into the big-bang release, they can still provide value to your customers later on. Keeping a few of these value-adds in your back pocket also has the added benefit of building a backlog of fast-follows for your next release, and contributing to a regular cadence of feature releases that you can continue to promote.
Don’t burn it
If you keep building for too long your people will burn out. It’s a hard slog to the finish line, and project fatigue will start to drain even the most tenacious designers & engineers. After a long lead time, shipping a big release into production can be a relief, along with a huge morale booster. Suddenly that project that’s been flying under the radar will be seen and experienced by countless users. The team is refreshed by the excitement and euphoria of the release, and happy to dive into further enhancements and bug fixes once the anxiety of the behemoth release is behind them.
Don’t cook it just for you
Which is to say, before you commit the time to building something, make sure it’s not just something that works for your use case. Make sure there’s a validated customer need for the product or feature, and that it’s something that will provide tangible value to your user base.
Next time your team ask when we’ll know if we’re ready to ship?
“When the popping slows down, and we can smell the butter”