Plan like a weather forecast.

Check the weather tonight and you'll get three kinds of answer. Tomorrow: 70 and sunny, and you'll plan a picnic on it. The ten-day: rain probably moves in next weekend, so maybe don't book the boat yet. The seasonal outlook: a wetter spring than usual. You won't plan a single day on that last one, but you might buy the rain boots.

Nobody calls the forecaster a liar when the ten-day changes. They told you how sure they were. They update on a schedule. And each horizon is useful for a different kind of decision.

Most companies plan the opposite way. Every quarter gets the same confident plan, with no stated certainty, and then everyone acts surprised when the back half of it doesn't happen.

Why the quarter kept failing us

I moved a product org off quarterly and half-year planning for two reasons.

The first was that a quarter was too short. The meaty, valuable, difficult things don't fit in thirteen weeks. Work like that either gets chopped into pieces that each look fine and add up to nothing, or quietly rolls from quarter to quarter while the plan pretends otherwise.

The second was the gap at the start of every period. You'd plan the second half of the year in May or June, a month and a half or more before the work started. Meanwhile teams would reach the end of one period with no real idea what they were supposed to be working on a month later. So the first month or so of every execution period turned into an extension of planning and ramp-up. Every period, we lost a month to getting ready.

Three horizons, three certainties

What we moved to was a rolling plan with three horizons. Each one had a stated level of certainty and its own update rhythm.

The 3-month commit, at about 90% certainty, updated every month. This is tomorrow's forecast. The teams are working it now, and it should mostly hold. Each monthly update carried two things: what we'd learned in the last month, and the commit going forward.

The 9-month roadmap, at 60 to 80%, updated every three months. This is the ten-day. It's good enough to make decisions with, like hiring, sequencing, and what to tell a big customer, and everybody knows parts of it will move.

The 2-year vision, at about 30%, updated every six months. The seasonal outlook. It tells people which way the organization is leaning, so near-term choices don't quietly work against where the product is heading. Nobody should plan a sprint off it.

Saying the number out loud did a lot of work. When the roadmap says 60 to 80%, a slip on something nine months out is just the forecast doing what forecasts do, and nobody has broken a promise. And when the commit says 90%, a slip there really is news, and it gets treated like news.

Office hours, not a planning tool

The monthly update had a second piece: office hours for the strategic leads. Anyone in the org could join and talk through the commit or the roadmap.

That sounds small. It wasn't. A plan that lives in a tool three people can open is a private opinion with a deadline. Office hours meant an engineer who saw a dependency coming, or someone in support who knew a customer was about to churn, had a place to say so before the next update, not after. It also kept the reason for the work attached to the work as it moved down the org, which is most of what goes wrong in planning. ("The game of telephone" is about that.)

The change that mattered most

Here's the change I'd make first if you only make one.

We assigned a Strategic Lead, a Delivery Lead and a Technical Lead to each major delivery before the planning period started. Not after the plan was approved. Before.

Those three people did the thinking that used to happen in the first month of execution. What needed to happen, what made sense and why, what it depended on. So by the time execution started, three, six or nine months out, someone had already been living with the problem. The teams walked into something that was ready for them to put their hands to the shovel.

That's what fixed the lost month: three named people owned the thinking ahead of time. ("Titles are for pay. Roles are for Tuesday." covers the three roles.)

A few things I'd hold to

Name the certainty on everything. If a line on the roadmap has no confidence attached, people will read it as 100%.

Update on the schedule, even when nothing changed. A forecaster who skips a day because the weather looks the same has stopped being a forecaster. "No change, here's why" is a perfectly good monthly update.

Let things move between horizons out loud. When something on the 9-month roadmap firms up enough to commit, say so in the monthly update. When something in the commit turns out to be a 60% item, move it back and say why.

Publish what you're not doing. It saves a hundred hallway conversations, and it tells people their idea was heard and placed.