Quarterly Roadmap Planning

This is where the quarter gets shaped. Not in Discover. Not in Define. Here. Quarterly planning is the moment where the team decides what problems are worth the next 13 weeks. Get this right and everything downstream has direction. Skip it, and the team optimizes locally, individually, and incoherently.

The output of this session is not a feature list. It is a prioritized set of bets: the problems we’ve decided are worth solving this quarter, why we believe they matter, and how much capacity we’re allocating to them. A bet is a belief, not a promise. The roadmap is your best judgment at the start of the quarter, not a contract.

Who and When

Who: All leadership stakeholders — not just the tech org. That means PM, engineering leadership, and whoever owns marketing, sales, operations, or any other function that will be affected by or expected to support what ships. Planning in a silo produces a roadmap that surprises half the company when it ships. Everyone with skin in the outcome should be in the room.

When: Planning starts in the last third of the current quarter — roughly the last four weeks. This gives the team time to build the candidate list, get rough sizing input from PE, and run the session before the quarter ends. The next quarter’s roadmap should be loaded into Glide before the first day of the new quarter begins. Teams that plan on day one of the quarter are already behind.

What comes before it: Learn. The retrospective from the current quarter is the direct input to planning the next one. What shipped, what didn’t, what surprised us, what the data showed. You plan forward from what you learned, not from what you hoped last time.

Pre-Work (PM Owns This)

The quarterly planning session is not a brainstorm. PM arrives with a prepared proposal. Leadership challenges it. The session should not be where you figure out what the problems are — that’s the pre-work.

Before the session, PM prepares:

A candidate list. Four to seven problem areas worth considering for the quarter, ranked by PM’s best judgment. Not features, not solutions — not yet. Each candidate should answer: who has this problem, why it matters, what the data shows, and what happens if we don’t address it this quarter.

Rough size signals. At this stage, no Discover or Define has been done, so no one can size the work precisely — and that’s expected. What you can do is get a directional read: does this feel like a few days of work or a few weeks? PM should loop in PE early for any candidate that looks non-trivial. PE gives a rough signal based on what’s known about the problem, not a firm estimate. Treat any size at this stage as an order of magnitude, not a commitment. The real sizing happens once Define is done.

One more thing worth noting: because AI handles most of the implementation, the real effort in any item is in Define and testing, not in building. A pebble that takes two person-sprints might be three days of Define, one day of AI-driven build, and the rest in QA, edge cases, and validation. Size accordingly — the build is not the bottleneck.

A capacity budget. Before picking any items, allocate the quarter’s capacity by category. Start with total person-sprints available, subtract planned leave and overhead, then assign a percentage to each type of work before any specific items are named.

These are not fixed rules. They shift quarter to quarter based on where the pressure is, and they look different depending on the company’s maturity and growth stage. A startup still finding product-market fit will weight product heavily and spend almost nothing on compliance. A company going through rapid expansion shifts toward that bucket. What matters is that the allocation is an explicit decision made before the session, not something discovered after you’ve already over-committed.

An online food delivery app as an example — a few years old, operating in multiple cities, actively expanding to new ones:

If the company is launching in three new cities that quarter, the expansion bucket grows and product shrinks. If there’s been a spike in payment fraud, security takes more. These decisions get made at the start of each quarter, not mid-sprint when the pressure is already there.

A proposed slate. PM’s recommendation: which pebbles to commit to, in what order, mapped to the capacity buckets. Bring a point of view, not an open question.

Running the Session

Part 1 — Present the candidates. PM walks through the candidate list: the problem area, the data behind it, the rough size signal. No selling. Just the case as clearly as you can state it.

Part 2 — All stakeholders probe. This is the core of the session. Everyone’s job is to challenge every item on the list:

• Is this the right problem, or a symptom of something bigger?
• Is the scope right? Too wide, too narrow?
• Does this fit where we’re going, or does it solve something that’s already good enough?
• What’s our conviction here — are we confident this is real, or are we exploring?
• What would we have to believe for this to be the highest-ROI thing we could do this quarter?
• Does marketing need to be involved when this ships? Does operations? Who else needs to know?

The candidates that survive this are the ones worth committing to.

Part 3 — Set the pebbles. Agree on the pebbles for the quarter. These are the primary unit of work. Most quarters will be entirely pebbles and sand. That’s not a lack of ambition — it’s a sign of good scoping. Smaller, well-defined items ship reliably and compound over time.

Rocks are rare. A rock only makes sense when the work represents a new revenue stream or a major platform shift that genuinely can’t be broken down into sequenced pebbles. If something looks like a rock, the first question is always: can we scope the first meaningful pebble out of it and start there?

For each item, agree on: the problem area, the time budget, and the owner.

Part 4 — Capacity check. Do the math against the capacity budget set in pre-work. Everything on the slate should fit within the budgeted categories. If it doesn’t, cut — don’t negotiate by assuming things will go faster than expected. Assume they’ll go slower.

What Goes Into Planning (Before Discover Is Done)

This is the question most teams don’t ask explicitly: if Discover happens after planning, what exactly are we putting on the plan?

At planning time, you haven’t validated anything yet. You haven’t confirmed the problem is real, you haven’t scoped the solution, and you don’t have a definition doc. What you have is:

A metric goal. Something you want to move. “Reduce checkout abandonment from 40% to 25%.” “Get onboarding completion above 70%.” “Cut support ticket volume on payment errors by half.” The metric gives the pebble a success condition that doesn’t depend on knowing the solution yet.

A narrative bet. A belief about what’s causing the problem and what might fix it. “We believe the tracking screen is creating anxiety for users after they place an order, and that improving it will increase repeat purchases.” The bet doesn’t have to be right — Discover will stress-test it. But it should be specific enough to know what you’d look at.

A time budget. Because you don’t have a definition yet, size by budget rather than by solution. How much are we willing to invest in this problem this quarter? Set the box. Let Define work within it. If Define reveals the problem is smaller than expected, you under-spent — great. If it’s bigger, you either narrow the scope or revise the roadmap. But you don’t expand the budget without a conversation.

This is why time-boxing is the default sizing approach at planning time, not solution-based sizing. Solution-based sizing requires a solution. At planning, you don’t have one yet. Trying to size before Define produces numbers that feel precise but aren’t — you’re sizing a story you invented to fill the gap.

Sizing in the Context of a Quarter

The sizing categories are not just labels. They are decisions about how much of a finite resource to allocate.

Solution-based sizing works when the problem is well-understood and the solution space is reasonably clear — for example, a known bug with a known fix, or a UI improvement where the change is specific. In these cases, PE can sketch a rough approach and give a directional size. Still approximate, but grounded.

Budget-based sizing (time-boxing) is the right default for anything less certain. Decide how much you’re willing to invest, set the box, and let Define operate within it. The mistake is applying solution-based sizing to abstract problems — you’ll either inflate the estimate to cover uncertainty, or underestimate because you’re reasoning about a solution you haven’t defined yet.

Pebbles (1–2 person sprints) are the default work unit. Well-scoped, shippable within the quarter, and sized so that Define and testing — where the real effort sits — can be done properly. Most of the work on the roadmap should be pebbles.

Sand (less than 1 person sprint) is bugs, urgent requests, configuration fixes, and small improvements. It doesn’t disappear because you didn’t plan for it. The capacity budget accounts for it by category before any items are named.

Rocks (more than 2 person sprints) are rare. A rock is justified when the work is a new revenue stream or a structural investment that genuinely can’t be delivered in increments. Before calling something a rock, always ask: what’s the first pebble? Usually the answer exists, and the rock dissolves into a sequence.

Sequencing

Once the pebbles are set, agree on the order.

Start with the item that has the most uncertainty — the one where Discover might change the scope the most. Finding that out in week two is much better than week eleven.

If items are independent, run them in parallel across engineers. If one depends on another, sequence them and finish the dependency first.

Within each item, milestones should produce working software every two weeks. Not internal milestones. Something PM and leadership can look at. If a milestone isn’t externally observable, it’s not a milestone — it’s a task.

The Output

When the session ends, you have:

• A prioritized pebble queue — each item with a problem area, metric goal or narrative bet, time budget, capacity category, and owner
• Any rocks explicitly called out, with a clear justification for why they can’t be broken into pebbles
• A capacity check that confirms the slate fits within the budgeted categories
• A sequencing plan that says which item starts first and why

This all lives in the Roadmap in Glide. Each item is a roadmap entry. PM is the owner. The status starts at Discover.

The roadmap is visible to clients and internal leadership at any time. It should always reflect what’s actually happening, not what was originally planned. If something changes during the quarter — an item gets re-scoped, a new priority emerges, a pebble grows — update the roadmap immediately.

Connection to Discover

Quarterly planning identifies what’s worth discovering. Discover confirms whether the bet is real.

Each item on the roadmap enters Discover the moment planning ends. PM takes the problem area, metric goal, and narrative bet from planning and begins the discovery process: validating against data, sharpening the framing, ruling out non-tech solutions, and bringing it to leadership before Define.

The inputs from planning are a starting point. Discover will sharpen them, and sometimes change them entirely. That’s expected and correct. If Discover finds that the problem isn’t what you thought, the roadmap updates. If the time budget turns out to be the wrong size, the roadmap updates. The roadmap is not a contract — it’s a live view of the team’s best judgment.

Next: Discover