We just closed out quarterly planning. Five product areas, two days, one room. It was chaotic. People talked over each other, trade-offs got argued out loud, and more than once I watched a roadmap I'd been carrying around in my head get challenged into something better. Somewhere on day one I had to remind myself: this is exactly how planning should feel.
Some of the chaos was the good kind, the debate. Some of it wasn't. We didn't have the right people in the room from the start, and spent the first stretch summoning busy senior people in once we realised they needed to be there. That's a different kind of chaos, and it's avoidable: know who needs to be in the room before the room starts, not partway through.
If your planning session is calm and orderly, you're probably not planning, you're ratifying decisions someone already made. The discomfort is the work. Robust debate is what happens when people who actually own the outcome, product, engineering, design, show up and disagree about what matters most. The framework matters less than the fact that the room had to fight for it.
That said, the framework helped. This round, we introduced a simple lens: every product line sits in exactly one posture, Defend, Grow, or Moonshot. Defend means protect the core; the bar is reliability, not growth. Grow means turn single-product wins into platform relationships, deliberately. Moonshot means place an asymmetric bet on where the category is heading, before someone else owns that ground. The point isn't the labels. It's that forcing each area into one posture kills the instinct to call everything equally important, which is how roadmaps quietly become 30 things instead of 3.
But here's the bit I keep turning over. This is now my third product org, and each one planned completely differently, and each approach made sense for where that org was.
One org ran a strict cadence: quarterly plans nested inside half-yearly ones. Clean on paper. In practice, prioritisation seemed to reset with stakeholders every single cycle, not a re-view of the existing plan, but a blank sheet. It started to feel like Groundhog Day1: relitigating the same trade-offs every few months because nothing carried forward as settled.
Another org didn't really "plan" in the quarterly sense at all. Roadmaps were rolling, now, next, later, and teams worked kanban style, with discovery workshops ahead of each piece of work and an inception when it was actually ready to start. No big bang planning event, just continuous shaping.
And now this: a structured two-day quarterly sprint, intense and a little chaotic, but with a framework that forced focus.
None of these is "the" right model. Each was the right model for that org's size, maturity, and how much certainty the business actually had at the time. The mistake would be assuming you can lift the framework from one and drop it into another. There's no template that fixes planning. There's only an honest read of where your org actually is, and the discipline to pick, or build, a framework that fits that stage.
What doesn't change, regardless of stage, is the substance underneath the format. You still need a shared understanding of what you're actually trying to achieve, and shared ownership of the outcome, not just product nodding along. That means engineering leaders and design leaders need to be in the room when the trade-offs are being made, not briefed on them afterwards. Planning is where technical feasibility, design judgement, and commercial reality should collide on purpose. If that collision happens later, in delivery, it costs more and it's harder to walk back.
There's also a temptation right now to treat planning rigour as old fashioned. AI is compressing how fast things can get built, and a quarter can suddenly feel like a long time to wait to decide anything. I'd argue the opposite is true. When build time shrinks, prioritisation and sequencing become more valuable, not less, because the cost of building the wrong thing fast is still the cost of building the wrong thing. The same discipline has to show up earlier and tighter: faster feedback loops with clients, faster iteration on what you ship, faster go-to-market motion. Speed doesn't remove the need for sequencing. It just compresses the window you have to get it right.
So if there's one thing I'd take from three very different planning cultures, it's this: stop looking for the template. Look honestly at where your org is, hold onto the things that don't move, shared outcomes, the right people in the room, ruthless sequencing, and build the rest around that.