Quarterly planning is a scarcity ritual
The Inference
SubscribeSign in
Quarterly planning is a scarcity ritual<br>The goal-setting ceremony assumes shipping is expensive. It isn't anymore.
Michael Mayernick<br>Jun 25, 2026
Share
Most teams I talk to set goals the same way they did five years ago. Build feature X, hit metric Y by date Z. OKRs, ownership, quarterly commitments, roadmap negotiations. All of that ceremony was designed for a world where shipping was expensive. You planned carefully because building was slow and you couldn’t afford to get it wrong.<br>I’m not sure shipping is expensive anymore. A small team with good agent workflows can ship a feature in days. But the ceremony hasn’t caught up, and I think the problem is deeper than just inefficiency. The planning ritual teaches carefulness as a virtue: protect the roadmap, don’t waste a sprint, make sure every feature is justified before you build it. That made sense when shipping was the bottleneck. Now you’re planning for a quarter when the game has moved to days. It keeps your thinking small, your learning slow, and your company behind.<br>Thanks for reading The Inference! Subscribe for free to receive new posts and support my work.
Subscribe
What’s actually scarce now is knowing what to build and whether it worked. Understanding the customer, the market, the codebase well enough that you can keep shipping and learning rather than carefully guarding a quarterly plan. Which means the interesting goal might not be “build X” but something more like “build the system that increasingly knows what to build, can validate whether it worked, and keeps learning and shipping on its own.”<br>What this looks like in practice
Old goal: “Build a measurement and experimentation system by end of Q3.”<br>New goal: “Build the development workflow where shipping a measurement system, or an experimentation system, or anything else we decide matters, takes weeks instead of months, and each project makes the next one faster.”<br>Old goal: “Launch one pilot with a real customer.”<br>New goal: “Build the feedback loop that makes every future pilot cheaper to run and faster to read.”<br>Both versions require doing the same work this quarter. The difference is what you protect when things get tight and what you measure to know if you’re succeeding. The first version optimizes for a deliverable, the second optimizes for a capability that compounds.<br>Where we hit this concretely
We ran into this in our own H2 planning at BotBot. The first draft felt familiar: work backward from target metrics, imagine features, assign owners, commit to a date. Build the measurement system, run a pilot, ship experimentation. The usual ceremony.<br>But we kept noticing that shipping the features wasn’t really the hard part anymore. With improving agent workflows we can ship features in days instead of months now. What’s actually hard is knowing which features matter, whether they worked, and what to try next. The spec pipeline we built last quarter ended up mattering more than any individual spec it produced, because it’s the thing that makes the next feature cheaper and faster and better informed. So the top-level goal became the system itself: build the capability to absorb signals from customers, market, and codebase, validate what works, and keep shipping and learning. First feature sets the baseline, third feature has to be 30% faster, and by month six we’re targeting 50%.<br>The tension showed up immediately, though. “We’re building the system” can easily become a way to never be accountable for a result. Speed as a goal sounds good until nobody checks whether you actually got faster. So we held both: the system goal on top with concrete delivery targets underneath it. If we can’t show the compounding in real cycle-time numbers, the philosophy isn’t working and we stop pretending it is.<br>What changes in how you plan
When this clicks, a few things shift in how you think about planning.<br>The first is what you protect when scope gets tight. The instinct is to cut the “meta” work and protect the feature, but I think you should invert that. Protect the learning loop, the verification pipeline, the development workflow. Defer feature scope instead, because one quarter’s feature is one quarter’s output while the system produces every quarter’s output.<br>The second is what you measure. Lines shipped and features launched are trailing indicators of a team that already works well. The leading indicators matter more: cycle time from idea to validated outcome, what percentage of verification is automated, how fast a new team member or a new agent becomes productive, and whether you can actually show that project three was faster than project one.<br>Careful is the wrong posture when shipping is cheap and learning is the bottleneck.
And the third is what posture your goals encourage. Quarterly planning teaches teams to be careful: protect the commitment, don’t waste the sprint, justify before you build. But careful is the...