I was helping a client recently with the beginning of their OKR journey. One of the success criteria I stress is an early and frequent analysis of data, both qualitative and quantitative, that indicates the work we’re doing is indeed progressing towards our desired goals (or not). If the key results are trending towards our goal, we keep moving forward, optimizing, iterating and improving. If it’s not, we take a hard look and decide if we’re going to pivot (keep the strategy but change the tactics) or kill the idea outright and turn our focus to something new. The client brought up an interesting question, “What if the work we’re doing is a ‘big bang’ release like a complete redesign and the company’s preference is to do all the design and development work up front and then launch?” How do we reconcile this with our OKR process?
Big changes come with big risk
I know it sounds obvious but it’s a commonly ignored reality in most orgs. The bigger the release, the more the organization has invested in it. You’ve spent time, money and effort to develop it. You’ve set expectations with customers, vendors, the market, and your shareholders that it’s coming and that it will be impactful. Not only have you accumulated a tremendous amount of risk by the launch date, you don’t have any clear signals from the market that the big release will deliver the results you’ve promised.
If the big bang release is your first and only attempt at hitting your key result goals for the next several quarters, what are you going to do if it doesn’t work? What if your customers hate it? What if it drives churn rather than the acquisition growth you predicted? How much appetite will the company have to go back and revisit this idea?
There is always a way to de-risk a big bang release
I understand that in some contexts a big bang release is the preferred approach. Perhaps you have a seasonal business that requires innovation by a certain consumer-mandated deadline? Maybe the competition has eclipsed your user experience that only a big leap forward will get you back in the game? Regardless of the reason, there are always ways to de-risk big bang releases and ensure that when they do go live they stand the greatest chance of delivering on our OKRs. Here are 3 ways to de-risk your next big bang release:
- Customer interviews – This is the cheapest, fastest and most effective to start building some feedback into your big bang product development process. Regular weekly conversations with a handful of users ensure you’re addressing the most current customer concerns. They provide you with insight as to why the competition is enjoying more success than you. They generate new insights that enable innovations you may not have considered when you planned the big project.
- Prototyping – If you’re planning a big bang release, you likely have an idea of what it will look like and how it will work. Prototype it. Use whatever the easiest method is for your teams. It doesn’t have to be working code. You could just as easily fake the user experience with paper. Prototyping will provide hints whether a full scale deployment of your big idea will drive the desired outcomes (key results). It’s not fool-proof. False positives can occur but it’s better than simply hoping it will work.
- A/B testing or limited release – A big bang release doesn’t have to go out to all of your users all at once. Consider rolling it out to a small slice of your population once you have a working version. See how they respond. Does their behavior reflect the predicted goals? If not, run more customer interviews. Learn where to make improvements and redeploy to the original audience slice. Once you start to see good results in your test group you can deploy more broadly with more confidence.
All of these techniques will generate insight. This insight will inevitably contradict your plan. While you may be committed to the big bang release, there’s no reason why you can’t adjust the plan en route to the big launch day. Ensure there is bandwidth with your teams to make these adjustments.
There is no reason to do big bang releases
My friend Jeff Patton teaches the teams he works with a simple question to consider whether to go through with any release, big bang or otherwise. The question is, “How much are you willing to bet me that you’re right?” He then offers a series of increasingly more valuable choices:
- A ham sandwich
- A week’s vacation
- A year’s salary
- Your left arm (ha!)
Though I’ve shared a few ways to think about reconciling your objectives and key results with your big bang release, I’d be remiss if I didn’t explicitly call out that there’s just no need to do big bang releases these days. The common pushback to this is that initiatives like “redesigns” cannot be broken down into smaller, testable pieces. And yet, how much would you be willing to bet that it will achieve your goals?
You may not be able to “slice up” a new design for your website or application into smaller parts but you can slice up the amount of effort you put into it. Wireframes, mock ups, clickable prototypes, even live data prototypes can start to deliver insight on these big ideas very quickly.
Use these tools to build confidence in the release. With a continuous deployment infrastructure we have the ability to go from prototype to production quickly. Get ideas out into the hands of your users quickly, sense the impact on their behavior and respond with another quick iteration. When you can confidently answer the “bet” questions with, “I’d bet a year’s salary” or something even higher, you’re ready to launch while standing a much greater chance of achieving your OKRs.