In one sentence
Effective prioritization is not about ranking all work with one universal metric. Different work horizons require different goals and decision processes: maximize strategic impact for Rocks, measurable short-term ROI for Pebbles, and execution throughput for Sand.
Overview
Cohen argues that the usual Rocks–Pebbles–Sand analogy is incomplete when treated merely as a size or scheduling rule. The categories represent three different kinds of work, each with its own time horizon, objective, prioritization method, and management role. Rocks are rare, strategic bets that may consume 3–12 months and must be important enough to justify overruns or underperformance. Pebbles take roughly 1–4 sprints and should produce measurable near-term value efficiently. Sand consists of work that fits within a sprint—bugs, security patches, refinements, refactoring, documentation, and other quality improvements—that matters cumulatively rather than individually. Sprint planning should handle time-critical work first, then the current Rock, then a Pebble, and finally Sand, while avoiding excessive context-switching and administrative overhead.
Core ideas
The categories are different mindsets, not just sizes
Rocks, Pebbles, and Sand differ in purpose as well as duration. Rocks look years ahead and serve strategy; Pebbles address current tactical opportunities; Sand improves the product through accumulated small gains.
Rocks maximize impact
A Rock should materially advance the company’s strategic position, not merely provide incremental improvement. Because large initiatives commonly take longer and achieve less than expected, the proposed impact bar should be unusually high. If no idea is genuinely great, do not choose a merely acceptable large project; use smaller work while developing and validating better ideas.
Rock decisions should be deliberate
Agile execution is useful after the destination is chosen, but it cannot rescue a team climbing the wrong strategic mountain. Executives ultimately own the strategic choice, while the product manager should ideally drive the analysis and proposal.
Pebbles maximize ROI
Pebbles are tactical projects lasting several stories or sprints that must produce objective, measurable value. Their proper question is: what is the most effective use of the team’s limited time right now? If a Pebble grows beyond four sprints, reduce its scope or reclassify it as a Rock.
ROI estimates are fragile
Small errors in expected impact and effort can radically distort calculated ROI. For example, a 20% impact shortfall combined with 50% extra effort can cut apparent ROI roughly in half. Rubrics and spreadsheets therefore create false precision when estimates are noisy; judgment remains essential.
Sand maximizes throughput
Small tasks often have little individually measurable impact, but their accumulation produces polished interfaces, robust error handling, better performance, safer dependencies, cleaner code, and stronger documentation. Success is the number completed, not a calculated impact score.
Do not bureaucratize Sand
Planning, templates, meetings, estimation, and ticket rituals can take longer than the work itself. Engineers should be able to handle much Sand directly, and teams should generally schedule it themselves. For low-risk items, desire and available energy can guide selection better than elaborate prioritization.
Time-critical work is an exception
Security patches, customer-impacting bugs, and immovable launch obligations come first regardless of category. But if urgent work consistently prevents progress on strategic and tactical work, that indicates a deeper capacity, staffing, architecture, ownership, or prioritization problem that deserves explicit attention.
Practical takeaways
- Classify work by its objective and horizon, not only by estimated duration.
- Keep the number of Rocks very small—possibly one major initiative in a year—and demand extraordinary strategic impact.
- Make Rock selection a deliberate strategic decision; once chosen, remain flexible about implementation details.
- Use Pebbles for measurable near-term wins. If one expands beyond four sprints, cut scope or reconsider it as a Rock.
- Do not use ROI calculations as if they were precise measurements; estimates are often too inaccurate for fine-grained ranking.
- Reserve Sand for the many small improvements that create quality, but minimize process overhead around them.
- A practical sprint order is: time-critical items, current Rock, current Pebble, then Sand.
- Avoid running multiple Pebbles simultaneously unless one is nearly complete or blocked for a substantial period; context-switching is costly.
Caveats and counterpoints
- The framework assumes a product team with enough autonomy and a reasonably clear company strategy. If strategy is vague, Rock selection becomes arbitrary rather than deliberate.
- The categories can blur: a small task with measurable business impact may function like a Pebble, while a seemingly large project may lack enough strategic value to qualify as a Rock.
- The essay strongly favors throughput and intuition for Sand, but safety-, compliance-, or reliability-critical small work may still require formal controls and explicit sequencing.
- The recommendation to let teams self-schedule Sand depends on teams understanding customers, technology, and business context; without that competence, autonomy alone will not produce good choices.
- The article emphasizes focus over perfectly balanced sprints. That can improve delivery, but sustained neglect of one category—especially maintenance Sand—can create delayed costs and operational risk.
Questions worth revisiting
- What current initiative truly has enough strategic impact to be the team’s Rock?
- If the current Rock under-delivers, would its impact still justify the time invested?
- Which candidate Pebble has the clearest measurable value within four sprints?
- What work is being slowed more by administrative process than by technical difficulty?
- Are urgent requests crowding out strategic work because of genuine emergencies, weak capacity, or poor boundary-setting?
- Over several months, are Rocks, Pebbles, and Sand all receiving enough attention—even if individual sprints are intentionally unbalanced?
Return to this when…
Return to this when planning a product roadmap or sprint cycle that feels busy but strategically stagnant. The most useful reminders are: do not confuse activity with impact, do not rank every task with the same framework, protect the Rock from urgent work, and remove bureaucracy from Sand.