Quarterly Planning Template for Product Planning

Two to three objectives with two to three key results each. More than that diffuses focus. If you have four or more objectives, you are either covering too broad a surface area or not making hard enough trade-offs. A single team cannot meaningfully move more than 6-9 key results in a quarter. The [OKR glossary entry](/glossary/okr-objectives-and-key-results) covers OKR-setting best practices.

A common split is 60% new features, 20% technical debt, 10% bugs, 10% buffer. Adjust based on your product's maturity. Early-stage products can allocate 70-80% to new features. Mature products with scaling challenges may need 30-40% on infrastructure and debt. The key rule: never go below 15% on technical debt or you accumulate compounding problems. Your engineering manager should co-own this allocation.

Missing OKRs is expected if targets are appropriately ambitious. Google's rule of thumb is that hitting 70% of stretch targets indicates the right level of ambition. The important thing is understanding why. Was the target too aggressive? Did scope creep consume capacity? Did a dependency slip? Capture these learnings in the end-of-quarter retro and feed them into the next quarter's planning. Never penalize teams for missing stretch OKRs. Penalizing misses incentivizes sandbagging.

Use the buffer (10% of capacity). If a change is larger than the buffer can absorb, treat it as a formal trade-off: something already committed must be deprioritized to make room. Document the swap in the quarterly plan. Do not simply add scope without removing scope. The [Product Strategy Handbook](/strategy-guide) covers change management within quarterly cycles.

Both. Leadership sets the strategic objectives (top-down). The product team proposes the bets, sizing, and capacity allocation (bottom-up). The negotiation happens at the intersection: are the proposed bets sufficient to hit the objectives? Is the capacity realistic? The best quarterly plans are co-created in a planning session where PM, EM, and design lead present their proposal and leadership asks questions, not dictates solutions. ---