The Week Before Quarterly Planning
Most quarterly planning sessions fail in the days before they happen, not in the room. Here's how to set up the pre-work that makes the session worth having.
Quarterly planning sessions have a reputation problem. Too long, too abstract, too many slides, not enough decisions. Teams leave with a vague sense of alignment and a roadmap nobody quite believes.
The session itself is rarely the real problem. The problem is the week before it — specifically, the absence of any structured pre-work that would make the session actually productive.
What happens without pre-work
Without preparation, the quarterly planning meeting does too many things at once. It surfaces information, debates that information, makes decisions based on that debate, and documents those decisions — all in the same session. That’s four different cognitive modes running in parallel, and it’s why the meetings feel exhausting and inconclusive.
The information-surfacing phase alone can swallow most of the available time. “Wait, what happened with the auth migration?” “Didn’t we say we’d finish the onboarding flow last quarter?” By the time the team is oriented to current state, there’s little energy left for forward-looking decisions.
The fix is to separate these phases. The week before the session: surface, orient, and gather input. The session itself: decide and commit.
Monday: update the canvas
Before anything else, the state of the current quarter needs to be honest.
Walk through every node on the current quarter’s canvas. Update statuses: what’s actually done versus what was marked in-progress and quietly stopped? Move anything that won’t ship this quarter to backlog. Be ruthless — a “done” count that includes things still in code review doesn’t help anyone.
This usually takes thirty minutes. The output is a canvas that reflects reality, not the plan you made ninety days ago.
Tuesday: write the retrospective context
Before looking ahead, capture a brief written summary of the quarter that’s ending. Not a formal document — a few paragraphs that answer:
- What shipped? What didn’t?
- What took significantly longer than expected, and why?
- Were there any dependency failures — things that blocked other things?
- What did users respond to? Any signal that changed your thinking?
Attach this to a canvas document or write it as a shared note. The goal is that anyone who reads it before the session understands the relevant history without needing to ask.
Wednesday: seed the forward canvas
Open the next quarter’s canvas. It probably has some cards already — items that were pushed from this quarter, ideas that have been collecting in the backlog. Now add the rest.
This is the input-gathering phase. A few approaches that work:
Async stakeholder input: Share the canvas with stakeholders and ask them to add their priorities to the “scope” (under consideration) area — not “todo” (committed). Anything goes in; the team will sort it. Give them until Thursday.
Backlog review: Go through the backlog systematically and pull anything that’s relevant for the next quarter into the “scope” cluster. This is the PM’s job, not a group exercise.
Engineering input: Ask engineers to flag anything with significant technical risk or dependency — things that affect sequencing even if they don’t directly appear on the roadmap.
By Wednesday evening, the forward canvas should be populated but uncommitted. Everything is up for debate. That’s correct.
Thursday: identify the open questions
With the canvas seeded, do one pass to identify what’s uncertain before the session. For each significant item, ask:
- Do we have enough information to make a commitment on this?
- Is there a dependency that isn’t resolved yet?
- Is there genuine disagreement about whether to do this?
Mark these explicitly — as a “scope” status, a comment, or a linked document with open questions listed. The goal isn’t to resolve them today; it’s to know what the session actually needs to decide.
Items with no open questions don’t need discussion time. Items with genuine unresolved questions do. Knowing the difference in advance is what lets you run a ninety-minute session instead of a half-day one.
Friday: send the pre-read
Send a brief summary to everyone who’ll be in the planning session:
- Where we ended the quarter (link to the retrospective notes)
- What’s on the canvas for next quarter (link to the canvas)
- The three to five questions that need to be decided in the session
One short document. If people read it over the weekend or the morning of, they arrive oriented. If they don’t, you still have it as a reference during the session.
This is the most skipped step, and the most valuable. A planning session where everyone walks in having seen the same canvas and the same open questions runs faster and produces better decisions.
What the session itself should be
If the pre-work is done, the session has a simple job: resolve the open questions and commit to the roadmap.
Walk through the canvas together. For items already agreed-on, move them from “scope” to “todo” and don’t discuss further. Reserve discussion for the flagged open questions. Make a decision on each, record it briefly in a linked document, update the status.
Close by looking at the committed quarter as a whole. Does the shape make sense? Is there a coherent story? Is anything overloaded?
Ninety minutes. Maybe two hours for larger teams.
The goal isn’t a perfect plan — it’s a plan everyone understands and can defend. That’s only possible if the inputs were shared before the meeting, not in it.
Do the boring work the week before. The session takes care of itself.