Operating Cadence Template for Product Managers

Review the cadence at every quarterly planning session. Make minor adjustments (timing, duration, format) at any retro. Major changes (adding or removing rituals, changing sprint length) should happen quarterly. The cadence should be stable enough that the team builds habits, but flexible enough to evolve with the team.

Two weeks is the default for most product teams. One-week sprints work for teams with high deployment frequency and mature CI/CD pipelines. Three-week or four-week sprints are rarely justified. The shorter the sprint, the faster the feedback loop, but also the higher the overhead ratio (planning and retro consume a larger percentage of the sprint). The [Product Operations Handbook](/product-ops-guide) covers sprint length trade-offs in detail.

Async by default. Switch to sync if the team is co-located and enjoys the daily face time, or if the team is consistently failing to resolve blockers through async channels. The purpose of a standup is to surface blockers and coordinate handoffs. If async achieves that, the meeting is unnecessary.

Protect the cadence by scheduling stakeholder meetings in dedicated windows. For example, reserve Thursday afternoons for external meetings. If a stakeholder requests a meeting during a protected focus block, offer the next available window. If the request is urgent, it is an escalation, not a standing meeting.

Resistance usually comes from one of two sources: too many meetings (cut some) or meetings that feel pointless (define clearer outputs). Ask the team which specific rituals feel like a waste of time and why. Often the issue is not the ritual itself but the facilitation or format. Try a different format before eliminating the ritual entirely. ---