Design Sprinting Your Way through AOP
This article first appeared in Medium.
Ah, it’s AOP season again — that magical time when we pretend to predict the future, armed with last year’s numbers, trendy buzzwords, and a year’s worth of ambition (and resources) represented in a few bullet-point slides. Thrilling, isn’t it? But what if we could transform this annual slog into an exciting opportunity for team alignment and — dare I say it — innovation? I recently stumbled on a way to accomplish just that.
Executives recently asked my team to show them what our product would look like if we continued building the roadmap over the next 12–18 months. Leaders in different parts of the company sought help aligning on the long(er) term plan. The ask, essentially, was to do a (form of a) design sprint and create a conceptual prototype to demonstrate what our product could look like in an 18-month horizon, which would conveniently put us at the end of the next fiscal year; see how this is starting to line up for a handoff to the AOP cycle like two team members handing off a baton in a relay race?
Anyway, I use the term “design sprint” loosely here. I’ve been a part of (and led) traditional design sprints as defined by Google Ventures and written about in several books, including the excellent book Sprint almost ten years ago. Design Sprints are awesome but also time — intensive… and draining. You genuinely feel like you’ve been doing a mental endurance race for the past week, like a weeklong triathlon… only less sweat (usually) and more sweets (always).
These workshops are usually worth it, though, as that amount of focused time can be remarkably productive. Unfortunately, taking that approach was not realistic for us in this situation, given some logistical hurdles; we decided to modify the activities and spread them out over two weeks as a virtual/remote exercise, given that folks were located across four time zones. The important thing is to structure the working sessions so you’re hitting each phase in the design sprint process.
Image of the 5 phases in a traditional design sprint
The artifact of our design sprint was a Figma prototype that we could get feedback on and show executives a tangible representation of where we think we are going. The intent was not necessarily to inform AOP, but a lightbulb went off for me after we had completed the workshop and presented it to executives.
First, if you are on the product side, we can all agree that NOBODY likes the AOP process except maybe Finance (apologies to my Finance friends). While companies undergoing digital transformation are encouraged to embrace a product operating model that leverages an agile funding approach — funding in shorter cycles that enables adaptability and a focus on outcomes over outputs — most companies are not there yet. In fact, most companies struggle to even think about making this shift to the ideal, more modern funding and planning model. I’m proposing a solution for scenarios where this ideal is not yet achievable but can be a stepping stone to get there.
A Real-World(ish) Example
This is the part of the article where I say, “based on actual events,” but from here on out, this is the “how might we” section — and I’m along for the ride with you. At the time of writing this, we are just on the precipice of AOP season. The rest of this article will be about where to go next.
After our pseudo-design sprint activities, I realized we had (unintentionally) created momentum that we could carry forward into the AOP cycle. Here’s why.
First and foremost, we now have a prototype that gives everyone a concrete view of how we might solve the problems identified on our roadmap. Part of the challenge with AOP is that we are still determining the solution at this point in the cycle; therefore, it is always a very abstract conversation. Rarely have we had the luxury to dig in with UX and engineering, let alone create a prototype. Having a “North Star” prototype — what we think our final destination looks like — removes much of the mystery. Even if we disagree, we can now have a tangible and productive conversation vs. a theoretical, abstract one.
Secondly, we can — and very much should — get more customer feedback than the quick down-and-dirty feedback we got during the design sprint. Admittedly, this is one of the main issues with AOP — discovery and customer feedback are nowhere to be seen in the process. Product teams are forced to define a solution to a problem/opportunity well before they have had time to focus and discover the right solution. As we all know, bypassing discovery activities and creating a solution is a cardinal sin in the product discipline, but this is essentially what AOP has traditionally been.
Thirdly, engineering now has a (modestly) better sense of what we might build and, therefore, a fighting chance at providing a more informed t-shirt size. Most people don’t say this out loud, but AOP estimates are, at best, wild-ass guesses that we force out of our poor engineering partners. They are often based on a short paragraph description and a few bullets describing the details… a very abstract and premature concept. A picture/prototype is worth a thousand words (or estimation meetings!).
These are all advantages that creating a North Star prototype leading up to the AOP cycle can afford companies. It’s like getting a jump start in a race or having a good tailwind catch your sails; it does not guarantee success, but it puts you in a much better position to achieve it.
Tips for How to Move Forward
If you like the idea of leveraging a design sprint and North Star prototype as input to your company’s AOP, here are some additional tips I have for moving forward.
First, align to *high-level* OKRs or outcomes. A 12–18 month horizon is probably the proper distance for alignment with company objectives without getting too far out ahead of yourself. I stress aligning to high-level OKRs or outcomes — you should not try to get too granular at this point or replace a quarterly OKR review cadence.
Second, leverage user research and feedback. This is a GREAT way to sneak in the voice of the customer and discovery activities into a process that typically overlooks this important input. I suggest going beyond what a design sprint typically captures in terms of feedback from a handful of users. If you create a North Star prototype early enough, you can plan to get thorough qualitative and quantitative feedback from customers.
Third, like all things in product, this comes down to prioritization. You are likely unable to run a version of a design sprint for every initiative or product on your 12–18-month roadmap. Pick the top 1–3 that have the most risk or ambiguity. Again, remember that you are only creating prototypes and not final designs at this point. However, making a prototype will help reduce risk and ambiguity, increasing the likelihood that you will begin your journey in the right direction for the new year.
Fourth, these prototype designs should be used to get buy-in from executives, alignment from stakeholders, and more confident size estimates from engineering. Engineering leaders abhor the inevitably crazy and urgent asks to provide estimates — even if they are meant to be high-level — for solutions that may only be described in a few short sentences.
Finally, consider doing this type of exercise more than 1x a year if at all possible. What if you did this 2x a year or more? Again, this should not replace your current discovery process (assuming you have one). This exercise looks further ahead than the immediate problems you are solving from a sprint-to-sprint or quarter-to-quarter perspective. However, it should work with your existing processes as these more extended horizon exercises can be an input to your regular, near-term discovery activities. Everything is, ultimately, an iteration of the previous work you do. The more iterations you do, the more you can spiral tighter and sharpen your focus on your product vision and roadmap while also allowing for adjustments along the way (i.e., agility).
Home Stretch
Look, I get it. Change is hard, especially when introducing a radical new step to something as entrenched as the AOP process. And I fully understand that, from the product perspective, we want to shift the conversation to a product/agile funding model. But the reality for most companies is that they are not quite there yet and certainly won’t get there in one fell swoop. Inserting discovery activities like a design sprint is a big step in the right direction and can perhaps serve as a stepping stone to help you get to the ideal funding model state in the future.
But to be clear, the goal is not to conduct a design sprint-like workshop for your team to simply check that box or to use it as a trojan horse for other motives. The goal is to inform planning conversations in the here and now; to sharpen the focal point on your long-term horizon by injecting some product management best practices (e.g., discovery, prototyping, and testing) into your company’s planning cycle.
Why not leap out of the starting blocks this next year? Your team — and maybe even your executive leadership team— might appreciate you redirecting them away from yet another marathon of soul-crushing spreadsheet reviews and never-ending estimation debates. Who knows? You might end up with an AOP that actually guides your company through the year to achieve your goals more effectively, rather than shackling your roadmap to a path formed by shots in the dark and then stumbling through for 12 months. Go ahead, experiment with this, and sprint yourself to a more productive AOP!
