Quarterly Look Ahead (QLA)

This post is a follow on from an overview of the Product Development Heartbeat. The Quarterly Look Ahead (QLA) is the part of that overall rhythm that pulls together teams, stakeholders and the wider org and helps with alignment to strategic goals and outcomes or objectives.

So, how to approach this Quarterly Look Ahead?

Hurry up and be patient!

First and most important thing to realise is that doing Quarterly Look Aheads (QLAs) takes a while to master. You can’t just flick a switch and be great at it. It’s like learning to ride a bike. Expect a few bumps and scrapes, but it does it get easier. The bigger or more complex your organisation and tech landscape, the longer it’s going to take to develop the muscle-memory and skills needed for this to be effective.

Having said that, if you can create a safe environment to experiment with this, you can get to a much better place fairly quickly, sometimes in just a couple of quarters. Making it safe takes effort and you have to be deliberate about it. You especially need to make sure that senior folks don’t destroy that by reacting badly when best-effort forecasting and guesstimation turn out to be exactly what they always were: a very brave attempt to predict the unpredictable.

So, the best time to start that learning is a year or so ago. The second best time to start is right now. It’ll take some time to strip away some of the bad habits and cultural norms that may have evolved to fill some of the vacuum. Persist with this and hopefully you can start to dissolve that build up.

Why bother with QLA?

With that said up front, let’s start with being clear about the why, the purpose of QLA – something you’re going to need to have to remind folks and newcomers of. The big picture “why” of QLA is to create and maintain some sort of alignment across your organisation, where you go through the painful process of figuring out what’s important and urgent right now, and cutting your cloth to fit.

Unless you have infinite capacity, you’re probably going to have to make some tough choices. The QLA proposes that you do that together, and be clear about what you are going to focus on, and what is going to have to wait. For each squad, you’ll hopefully arrive at some agreement about what to focus on and in what order. The “how long” question is mostly so that you can make tradeoff decisions and therefore put things into a sensible “order of attack”

Here’s a visual I’ve used to remind folks of the “why?”

Worth making it explicit what the expected outputs and outcomes are at the end of the QLA, alongside important words about not seeking precision.

If you understand that “Why” and you achieve those outputs and outcomes, it doesn’t matter so much how you run it. As a starter for ten though, here’s one way of doing that, starting the week following your Monthly Showcase:

QLA week – the order of events

QLA Kickoff – Start with Strategic Goals

If the strategic goals aren’t visible and understood and regularly repeated and linked to, you’re liable to start drifting from what the wider organisation is thinking. This is often only refreshed annually, but a better cadence for Product Development is to make small tweaks and adjustments quarterly. A gentle hand on the tiller is much better than letting things run a few degrees off course for a whole year. If I’ve learned anything about big initiatives, it’s that regular iterative course corrections is MUCH better than burning time, money and energy pursuing a fairytale.

For some organisations Strategy might look like OKRs (Objectives, Key Results), . Hopefully those are proper outcomes, and not just a list of things to do and deliver. (If you see the word “execute” or “Deliver” in there, that’s usually a bad sign.) However the bigger goals are articulated, this is the chance to say them out loud and help folks understand them.

One model for understanding the broader value piece that I’ve found useful is the four buckets of value, which gives you a mechanism to tie back to multiple end goals, and cover both Revenue and Cost sides of the equation, which tends to be fairly important to most orgs, even public sector and not-for-profits.

I also prefer GEMs: Goals, Experiments and Measures to OKRs. Same thing, but the language used hopefully fits Product Development better, and might help avoid rewording deliverables as OKRs.

I’d strongly recommend having some of the senior folks in your org outside of Product Development talk to the Strategy. More than 3-4 High Level Goals is a problem, and more than 3-4 experiments running per Goal at once is also going to be too much. Measures should triangulate, so you cover some of the tradeoffs.

Here’s a suggested run sheet, which covers the Monthly Showcase, with the QLA itself spread over a week, starting with QLA Kickoff, some work to pull together refreshed Roadmaps and Forecasts and then the QLA Postmatch, where that gets shared with the wider team. Three Wednesdays in a row each quarter gives it a good rhythm and isn’t too disruptive for squads who still need to support the products they are stewarding.

Kickoff – show what happened last quarter

Recommend using a CFD for this, with each squad talking to the flow of work to done over the quarter, with a few highlights and lowlights. The CFD helps with the sense of momentum, making it visible the work that the team got through. No doubt there will have been some surprises. Definitely call out any changes that might have improved or decreased the momentum.

Key point here though is to set the scene for the coming quarter by looking at what’s just happened in the rear view mirror. If your look ahead is more ambitious, what’s the change you’ve made that would potentially make that true? What have you done to improve this squad’s flow? etc. etc.

Kickoff – Draft Roadmap

If new options need to be considered, or something’s been done or not done and needs to be pulled forward or pushed back, then at least start with a sensible Product Team view of the art of the possible looking ahead. This shouldn’t be set in stone of course. The Roadmap is more like a menu of options to discuss and add or change. There’s conversations coming up, but we’re not starting from a blank page, so show that page. Not really for deep discussion in the Kickoff though, just a quick review of the current, pre-conversations with stakeholders and other squads.


There’s three main activities that are needed after the QLA Kickoff, which is where a lot of the value lies. Don’t rush this. The first is pulling together options for what each squad could focus on for the coming quarter. Usually, there’s many paths possible to achieve the desired outcomes. Some are faster, some slower, and there’s tonnes of tradeoffs in each of those. It might be that there’s some telemetry that needs to be put in place first, so the team can safely experiment. Other times the options involve paying down some outstanding technical debt so that the architecture reflects a better understanding of how the product is being used today and is likely to be used in the future.

Whilst it’s somewhat controversial, you do actually need some sense of the relative duration of those different paths. Not a precise estimate, and not so a fake deadline can be created – just enough to weigh up the options. You should of course also have some estimate of the value and urgency (i.e. Cost of Delay) and it’s when those two are put together you get a sense of the “money for mahi”. Share these assumptions with stakeholders, and don’t skip the part about the tech debt or other tradeoffs. Stakeholders can share their own views, but if there’s disagreement, that’s where the Product Lead will need to make a call.

slicing and forecasting

Having gone through the effort of choosing focus, the team can then invest time and effort into slicing the work into small enough pieces that we can build out a forecast. If they’re too big, expect a lot more things to emerge late in the process that hadn’t been thought of. You’ll also want to bravely line things up into a forecast. Use your prior quarter’s average throughput to guide this, and make adjustments based on how much is at stake with the forecast. Do you need it to be higher confidence, in order to coordinate other things? Or can a more risk-friendly forecast that is no better than 50% right ok? Don’t be tempted to waste too much time on this though. You can spend just as much time doing analysis that still turns out to be inaccurate than if you just got on with doing the most risky parts and make some progress toward the goal.

Walkthrough, feedback and iteration

Before you get to the Post Match part of QLA, don’t forget to check in with other squads (who may have dependencies) and other parts of the org who are working on related items. The version of the forecast that you walk the broader team through at the Postmatch shouldn’t be a surprise to stakeholders. Give them a chance to feedback and suggest changes in order at least. That forecast should absolutely be something the squad doing the work have had a lot of input into, of course. Having done that, you’re ready to put it all together and run through it with the broader organisation in the “QLA Postmatch”

TODO: describe how the Post-match at the end of the QLA works.