
The Weekly Rhythm: A 60-Minute Operating System That Actually Ships
Most "weekly planning" fails because it tries to plan everything. The goal isn't comprehensive planning, it's deciding what the week is for. Here's the 60-minute weekly cadence I've refined over years of leading product teams, and why simplicity beats thoroughness every time.
Weekly cadence is one of those ideas that sounds obvious and still fails in practice. I've watched it fail across dozens of teams, and the failure modes are remarkably consistent. Teams either don't plan at all and everything becomes reactive, or they plan too much and the plan becomes fantasy, or they plan tasks instead of outcomes and end up with busy weeks where nothing actually finishes.
A weekly rhythm works when it's small, repeatable, and tied to outcomes. This article walks through how I run weekly planning, issue-solving, and review in about 60 minutes per week total. If you want the big picture first, start with my article on the Business Operating System, this is the tactical implementation of that framework.
"Weekly planning isn't about planning everything. It's about deciding what the week is for."
The Three Moves
You only need three moves to run an effective week: Plan, Solve, and Review. Everything else is optional. I've seen teams add elaborate rituals, multiple check-ins, and detailed tracking systems, and I've watched those same teams abandon everything when the overhead becomes unbearable. Keep it simple, and it actually gets done.
Move 1: Plan (15-30 Minutes)
Planning has one job: turn strategy into a week you can actually finish. This isn't about comprehensive planning or covering all your bases. It's about creating clarity on what matters and protecting the time to make it happen.
The inputs you need are simple: a focus metric (or one key result), last week's completion rate, last week's learning note, and calendar reality, how much time do you actually have available. Without that last one, you're planning in a vacuum.
The Non-Negotiable Outputs
Every planning session must produce four things: one focus metric for the week, 1-3 outcomes with "done looks like" definitions, one issue to solve, and time blocks protected on the calendar to actually do the work.
- →One focus metric, What number will you move this week?
- →1-3 outcomes, What will exist by Friday that doesn't exist today?
- →One issue to solve, What's blocking progress?
- →Time blocks protected, When will the work actually happen?
The Questions That Matter
I've found that planning becomes efficient when you ask four questions in order: What metric matters this week? What 1-3 outcomes will move it? What issue is most likely to block those outcomes? And where will the work happen on the calendar?
If you can answer those four questions, you have a real plan. Everything beyond that is refinement. I've watched teams spend two hours in planning sessions that could have taken twenty minutes if they'd focused on these essentials.
Avoid Planning Task Lists
A plan that looks like "work on onboarding," "talk to users," and "fix bugs" is a trap. Those are categories of work, not outcomes. You can "work on" something forever without producing anything.
The difference is that outcomes have a finish line. You know when they're done. Tasks don't. Rewriting tasks into outcomes is the single highest-leverage improvement most teams can make to their weekly planning.
Protect the Week from Over-commitment
Weekly planning fails when you ignore time constraints. Two rules help: never commit to more than 3 outcomes, and schedule 2-4 deep work blocks before you add anything else. If the calendar can't hold the work, the plan is fantasy. Better to know that on Monday than discover it on Friday.
Move 2: Solve (30-45 Minutes)
This is the weekly issues meeting. Its purpose is not discussion, it's resolution. I've sat in countless meetings where the same issues got raised week after week without ever being solved. Those meetings are worse than useless because they create the illusion of progress.
The inputs are simple: open issues captured during the week, this week's outcomes, and the focus metric. The output is equally simple: 1-3 issues selected, 1-3 next actions total with owners and "done looks like" definitions.
The Meeting Structure
I use a simple three-step structure: Identify, Discuss, Solve. In the Identify phase, you list issues, cluster duplicates, and select the top 1-3 by impact and urgency. In Discuss, you align on what's true, evidence, impact, constraints, while avoiding drifting into solutions too early. In Solve, you decide the smallest next actions that reduce uncertainty or remove the block.
The Anti-Bloat Rules
These rules keep the meeting from turning into a two-hour debate. If you can't agree in 10 minutes, escalate to a deeper root-cause workflow for the top issue. Actions are capped at 1-3 total, not 12 "follow-ups." Every action has a definition of done and a date.
The hardest part of this meeting is saying no. When someone raises an issue that's clearly important but not in the top 3, you have to park it. This feels uncomfortable, but it's what makes the meeting work. Solving three issues completely beats discussing ten issues partially.
Move 3: Review (10-20 Minutes)
Review is the compounding step. Without it, you repeat the same week forever. This is the meeting that gets skipped most often, and it's the one that matters most for long-term improvement.
"The review is where compounding happens. Without it, you repeat the same week forever."
The output is just two sentences: your key learning (what changed, why, what it implies) and your next experiment (what you will change next week). Then you add one system improvement, tighten definitions of done, split outcomes smaller, add a checklist for a recurring process, or adjust the calendar so deep work happens earlier.
The Two-Sentence Review
I've found that constraining the review to two sentences forces clarity. If you can't summarize your learning in one sentence, you probably don't know what you learned. If you can't describe your next experiment in one sentence, it's probably too vague to actually run.
Running This in Practice
If you want a "just do it" starting point, use a single weekly note with your focus metric, 1-3 outcomes, top issue, and end-of-week review. That's it. You don't need a tool or a template, though both can help once the habit is established.
The key is keeping the documents short and repeatable. The moment your weekly note becomes a chore, you'll stop doing it. Better a simple system you actually use than an elaborate one you abandon after three weeks.
The Trade-offs
You will feel under-committed at first. 1-3 outcomes can feel "too small" when you're used to planning ten things. But finishing compounds. Every week you complete what you commit to builds confidence and momentum. Every week you over-commit and fail erodes both.
This rhythm doesn't replace strategy, it makes strategy executable. And the system is only as honest as your review. If you rationalize misses instead of learning from them, you lose the loop entirely.
Ready to Implement This Rhythm?
I help design teams adopt operating systems that ship faster without burning out. The key is finding the right balance for your context.
Let's Talk →Get AI-Augmented Insights in Your Inbox
Strategic frameworks, case studies, and lessons learned from building AI-native products. No fluff, just actionable insights for VCs and executives.