Setting & Hitting Quarterly Rocks for Indie Game Studios

This guide explains how to set and hit quarterly rocks for your indie game studio, using the Entrepreneurial Operating System (EOS) framework adapted for game development. You’ll define 3-7 concrete, measurable goals each quarter, then create a simple weekly process to track progress and keep your team focused. This turns vague ambitions into shipped features and real growth.

What You’ll Need

• A shared document or project management tool (e.g., Notion, Trello, Google Sheets)
• A regular team meeting slot (weekly is ideal)
• Your studio’s annual or long-term goals (to align rocks with them)
• A way to visualize progress (e.g., a physical board or a digital dashboard)

Step-by-Step

1. Review your annual goals. Before setting quarterly rocks, know what you’re trying to achieve this year. If you don’t have annual goals, spend a session defining them: revenue targets, game launch dates, player counts, or team size. Rocks are the quarterly milestones that make those annual goals real.
2. Brainstorm potential rocks. With your team, list everything that needs to happen in the next 90 days to move toward your annual goals. Think about game development milestones (e.g., “complete vertical slice”, “implement multiplayer netcode”, “finish art pass on level 3”), marketing (e.g., “grow wishlists to 10,000”, “release a demo to press”), and business (e.g., “sign a publishing deal”, “hire a community manager”). Don’t filter yet—just get everything out.
3. Select 3 to 7 rocks. From the brainstorm, pick the most impactful items. A rock must be something that, if you achieve it, makes the quarter a success. It should be specific and measurable, not vague. For example, “improve game feel” is too vague—”reduce player death-to-respawn time to under 2 seconds” is better. Avoid choosing more than 7; focus is key.
4. Assign one accountable person per rock. Each rock needs a single owner who is responsible for its completion. This doesn’t mean they do all the work, but they are the point person who ensures it gets done. Write their name next to the rock. If you can’t assign a single owner, the rock is probably too big or too vague.
5. Define the completion criteria. For each rock, write a clear statement of what “done” looks like. This should be binary: either it’s done or it’s not. For example, “Vertical slice playable from start to finish with placeholder art” is a clear completion criteria. Avoid criteria like “as good as we can make it”—that’s not measurable.
6. Break each rock into weekly tasks. Once you have your rocks, break each one into smaller tasks that can be done in a week. This is the key to making progress visible. For example, if your rock is “implement multiplayer netcode”, weekly tasks might be “set up server infrastructure”, “implement client-side prediction”, “test with 4 players”.
7. Create a weekly scorecard. In your project management tool, create a simple table or board with columns for each rock, its owner, and a weekly status (e.g., On Track, At Risk, Off Track). Update this every week. This is your “scorecard” that shows at a glance how you’re doing.
8. Hold a weekly rock review meeting. Set aside 30-60 minutes each week to review the scorecard. For each rock, ask: “Are we on track to hit this by the end of the quarter?” If not, discuss what’s blocking and adjust the weekly tasks. This meeting is not for status updates—it’s for problem-solving.
9. Update the scorecard after each meeting. After the meeting, update the status of each rock based on the discussion. If a rock is off track, note the key blocker and the plan to get back on track. This keeps the scorecard as a living document.
10. At the end of the quarter, conduct a retrospective. When the quarter ends, review each rock: did you hit it or not? Celebrate the wins, and for the misses, ask “what did we learn?” and “what will we do differently next quarter?” Then, start the process again for the next quarter.

Common Mistakes

• Setting too many rocks. If you choose 10 rocks, you’ll likely fail at all of them. Stick to 3-7, and if you’re a small team, lean toward 3-5.
• Making rocks too vague. “Improve graphics” is not a rock. “Finish the character model for the protagonist” is. If you can’t easily say whether it’s done, it’s not a rock.
• Not assigning a single owner. If everyone is responsible, no one is. Each rock needs a clear owner.
• Ignoring the weekly review. If you set rocks but never review them, they become wishful thinking. The weekly review is what keeps them alive.
• Setting rocks that are not aligned with annual goals. If your annual goal is to release a game, but your rocks are all about building a new engine, you’re off track.

Tips

• Use the “one thing” principle. For each rock, ask “What is the one thing that would make the biggest difference this quarter?” Prioritize that.
• Make rocks slightly ambitious but achievable. If you hit all your rocks every quarter, you’re probably not pushing yourself hard enough. But if you miss them all, you’re setting yourself up for failure.
• Break rocks into weekly tasks that are small enough to be done in a few days. This gives a sense of progress and helps you catch problems early.
• Use a visual board. A physical or digital Kanban board with columns for each rock can help the team see progress at a glance.
• Involve the whole team in setting rocks. When everyone has a say, they’re more committed to the outcome.

Troubleshooting

If you’re halfway through the quarter and a rock is clearly off track, don’t just let it slide. First, identify the root cause: is it a lack of resources, a technical challenge, or a scope issue? Then, consider these options:

• Re-scope the rock. Can you cut the scope to something achievable in the remaining time? For example, if “implement full multiplayer” is too big, reduce to “implement 2-player co-op”.
• Change the owner. If the current owner is overloaded, reassign the rock to someone with more capacity.
• Get help. Can you bring in a contractor or freelancer to help with a specific task? Sometimes a small investment can save the rock.
• If a rock is truly impossible, drop it and replace it with something else. It’s better to pivot than to waste the rest of the quarter on a lost cause. Just make sure you learn from why it failed.

Frequently Asked Questions

How many rocks should we have?

For a small indie studio (1-5 people), 3-5 rocks per quarter is a good target. For larger teams, up to 7 is manageable. Any more than that and you’ll lose focus.

What if we don’t hit a rock?

It’s not a failure—it’s data. In your retrospective, ask what you learned and what you’ll change. Sometimes you discover that the rock was too ambitious, or that you need more resources. Use that info to set better rocks next quarter.

How do we keep rocks visible to the team?

Use a shared tool that everyone checks regularly. A physical board in the office (if you have one) or a pinned document in Slack/Notion works. The key is that the scorecard is updated weekly and reviewed in the meeting.

Can we change rocks mid-quarter?

Yes, but only if there’s a compelling reason. If you discover a critical bug that requires a pivot, it’s better to change a rock than to stick to a plan that’s no longer relevant. Just make sure the change is deliberate and communicated.

Should rocks be only about game development?

No. Rocks should cover all areas that matter to your studio: development, marketing, business, and team health. For example, a marketing rock might be “grow our Discord to 5,000 members”.

How do we handle a rock that’s blocked by another team member?

In your weekly review, identify the blocker and address it directly. If someone is overloaded, redistribute work. If it’s a technical blocker, consider pairing up or seeking advice. The point of the review is to unblock, not to assign blame.

Related

• US Water Heater Calculation: Estimate Tank Size
• PPM Error Calculator for Mass Spectrometry
• Voltage Conversion Calculator: Volts, Millivolts and More