Rocks, Not Tasks: How to Commit to 1-3 Weekly Outcomes
The fastest way to sabotage a week is to commit to tasks instead of outcomes. "We'll work on onboarding" is a promise you can always claim you kept. That's exactly why it's dangerous. Here's how I've learned to define weekly outcomes that actually finish, and why the constraint of 1-3 is what makes it work.
I've watched this pattern play out more times than I can count. A team starts the week with a long list of things they're going to "work on." By Friday, they've touched everything and finished nothing. The next Monday, they do it again. Months pass. Major initiatives stay perpetually "in progress."
The problem isn't effort or talent. It's the way commitments are framed. Outcomes force clarity: what will exist by Friday that doesn't exist today? How will we know it's done? What metric should move if it worked? Tasks avoid these questions entirely, which is why they feel safer, and why they fail.
"If you can't write 'done looks like,' you don't have a Rock. You have a wish."
What a Rock Actually Is
A Rock is a weekly outcome, a shippable result with a definition of done. I borrowed the term from EOS (Entrepreneurial Operating System), but the concept applies regardless of what framework you use. The key is that a Rock produces something tangible. It has a finish line. You can look at it on Friday and definitively say whether it happened or not.
This is the critical distinction. "Work on onboarding" isn't a Rock because you can always claim you did it. You touched onboarding for twenty minutes, didn't you? Check. But "Ship a single-step onboarding with one primary CTA and an empty state" is a Rock because it either exists on Friday or it doesn't. There's no ambiguity.
The "Done Looks Like" Rule
Every Rock must include a definition of done. This isn't optional, it's what separates outcomes from activities. "Done looks like" forces you to describe the end state in concrete terms that anyone could verify.
I've found that writing "done looks like" is the best way to expose vague thinking. If you can't articulate what done looks like, you probably don't have enough clarity to execute effectively. Better to discover that on Monday than on Friday.
Why Only 1-3 Rocks?
Execution is constrained by time, attention, integration cost, and decision overhead. Most teams dramatically underestimate these constraints, which is why they over-commit week after week.
More than 3 outcomes creates predictable failure modes: partial completion across many items, constant context switching, and the dreaded "busy week, nothing finished" syndrome. I've seen this pattern so many times that I now treat it as a near-certainty when teams commit to more than 3 weekly outcomes.
Three outcomes is a forcing function. It makes you choose. And choosing, saying no to good things so you can say yes to the best things, is the discipline that separates teams that ship from teams that just stay busy.
"Three outcomes is a forcing function. It makes you choose."
How to Pick Rocks
I use a simple three-part filter when selecting weekly outcomes. Each Rock should move the focus metric, unblock other work, and be finishable in one week. If it fails any of these tests, it's either not the right Rock or it needs to be split.
The third criterion is where most teams struggle. They pick Rocks that are actually multi-week projects dressed up as weekly outcomes. "Refactor onboarding" sounds like a Rock, but it probably isn't. "Extract the onboarding step component and add one test" is closer to what can actually finish in a week.
The Most Common Mistake: Scope Creep Disguised as a Rock
These are fake Rocks: "Refactor onboarding," "Launch the new pipeline," "Rebuild the dashboard." They sound specific, but they hide multi-week projects inside one-week labels. I've seen teams commit to Rocks like these and then feel demoralized when they don't complete them, as if the problem were their execution rather than their scoping.
The fix is aggressive scoping down. "Refactor onboarding" becomes "Extract the onboarding step component and add one test." "Launch the new pipeline" becomes "Ship Step 1 with in-progress status and a retry button." "Rebuild the dashboard" becomes "Add one new card state and wire it to real data."
Writing Rocks in 5 Minutes
I use a simple template for each Rock that takes about a minute to fill out. The discipline of writing it down forces clarity that thinking alone doesn't provide.
After filling out the template, run two sanity checks: Can we ship this in a week with the time we have? And if we finish only this Rock, would it still be a good week? If the answer to either question is no, you need to adjust.
The Trade-offs
Tight Rocks can feel "too small" to people accustomed to ambitious planning. They're not. Finishing compounds. Every completed Rock builds momentum and credibility. Every failed Rock erodes both. Small and done beats ambitious and incomplete every time.
Outcome-driven weeks can surface uncomfortable truths, your plan was too big, your estimates were off, your priorities weren't clear. This is a feature, not a bug. Better to learn these things weekly than quarterly.
And yes, some weeks require emergency work. The system still helps by forcing you to define the outcome of that emergency work. Even in crisis mode, you can have a Rock.
Struggling with Execution Velocity?
I help teams implement operating systems that ship consistently. The key is finding the right constraints 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.