I have a friend. Every message she writes begins with “URGENT! IMPORTANT!”. I’m not kidding. She does that because she learned that if she doesn’t add those words and doesn’t use all caps, her message might get ignored. It turned into the story of the boy who always cried wolf.
In product development, the same thing happens inevitably, too. Everything becomes critical except for a few things. We must do this and that and a few more things, too. The “critical,” “important,” and “nice to have” grading system doesn’t work. There’s a better way.
The Rocks, Pebbles, Sand Metaphor
A metaphorical story illustrates the importance of prioritizing what truly matters in life. It involves a professor showing his students the nature of life using rocks, pebbles, and sand in a jar. The original author is unknown, but the tale was popularized by Stephen Covey’s famous book “The 7 Habits of Highly Effective People.”
In the story, a philosophy professor holds up a large, empty glass jar and fills it with big rocks, small pebbles, and finally, sand. The jar signifies one’s life, while the rocks, pebbles, and sand represent the different elements that fill it up.
Order of Priorities
The large rocks symbolize the most crucial aspects of life, like health, family, and relationships — things that give life meaning even if everything else is lost. The pebbles stand for other significant matters such as work or education. Though important, these are not as vital as the “big rocks.” Finally, the sand depicts the small, less consequential things and material possessions that don’t add much to one’s quality of life overall.
The professor shows that starting by filling the jar with sand leaves no room for the rocks and pebbles. The proper way is to put in the big rocks first, then the pebbles, and only after that the sand. This illustrates that focusing too much on the trivial stuff first may prevent giving the truly important things their due attention and priority. The moral is to put the “big rocks” — family, health, and relationships — first in life before addressing the smaller pebbles and sand.
Applying the Metaphor to Software Projects
This story is not just about prioritizing essential things in life in general. It’s also super relevant for prioritizing work on software projects.
We face an impossible task at work, just like in our personal lives. We have dozens of important new features that we need to build and are committed to delivering. We also have a handful of things we should address as they come up. Usually, those are relatively simple user requests. While small, they shape how users feel about the speed of development and support quality. Finally, there’s an endless flow of bug fixes, minor updates, maintenance tasks, refactoring, migrations, etc. Users don’t notice these things, but they must be done anyway.
Juggling all of that while moving product development forward is an art. The only way to get things done is to prioritize and focus on what has been prioritized.
The Critical Rocks: Prioritizing and Flexibly Managing Key Features
The first list is for rocks. Rocks are essential things you need to deliver for the business to get the value out of the development process. If you’re a commercial product, those features are your competitive advantage or things that will attract more users to sign up, use your product longer, or promote it to others.
This main focus likely consists of important things that take time to complete. You can break them into smaller pieces, but several steps are usually still involved. You’ll often have just a few of these rocks at a time to maintain focus.
Rocks tend to be on the roadmap as a commitment, but they can have differing business values and dependencies, requiring different levels of effort. Since rocks are often more extensive, the team constantly learns and gains new insights about them. Sometimes, the scope needs to be cut back, priorities shift because of dependencies, or specific skills are required but unavailable. You need to do more than freeze the list of rocks and complete them in roadmap order. The roadmap serves as a guide, but flexibility is required based on business value, effort, and learnings.
The Shifting Pebbles: Managing the Constant Stream
The second list is for pebbles. Pebbles are smaller-scale features and updates that usually take less time to analyze and implement than rocks. However, there are many more pebbles, and they are more dynamic in nature. For example, if you’re building an internal tool, a stakeholder might come to you and ask to add a way to generate an important report in the system, add a button, or change how X or Y is done. Sometimes, pebbles turn into rocks. Other times, some pebbles are time-sensitive or urgent, so it takes effort and energy to keep the list of pebbles prioritized and addressed because of their shifting nature.
As I said, pebbles are vital because they show how responsive your dev team is to the end users making requests. You want those users to feel good about the process, just as stakeholders do. Think of UI interfaces — your app can be as powerful and valuable as possible. Still, people will barely use it if it freezes for five minutes or crashes periodically. On the other hand, if it’s a friendly, simple app with a sleek, responsive UI and animations, your users will have a great experience and enjoy using it.
Since pebbles are dynamic, they usually require a lot of attention. End users need to be asked about the details of their requests and kept updated on progress. Sometimes, pebbles become massive things, so decisions must be made to turn a pebble into a rock, deprioritize it, or split it into pieces to do one by one with different priorities. Engineers working on pebbles must avoid getting stuck on one specific request from this list for long — usually, that’s a sign the piece of work needs a manager’s attention.
The Endless Sand: Managing the Neverending List
The third list is the sand. This seemingly endless list contains as many items as grains in the sand. New bugs constantly get reported as you build more features. The changes you implement create things to refactor and migrate. As time passes, you need to update more libraries and services. While you can’t avoid this work, stakeholders and end users don’t care about it — they only notice the value it brings. Still, you must address these issues before they become bigger problems.
The sand list requires constant attention and energy for any extensive system. QA and users report many bugs, but only a few are critical. You must rigorously prioritize the critical ones — can’t fix everything. Also, track which parts of the system generate the most bugs and which engineers produce the buggiest code. Though separate issues, these are worth monitoring. Additionally, tech leads always have a list of chores, refactors, and updates needed — these must be prioritized and addressed, too. Sometimes, these minor issues turn into pebbles or rocks requiring immediate attention.
Adapting Plans and Priorities
As project and product managers, we must track requirement lists, prioritize them, and ensure everything moves forward. But we must also know when to reprioritize and move items between lists — a part often overlooked.
This system is relatively simple because it lets you assign two grades to each piece of work: value to users and effort to complete. Every task can be a rock, pebble, or grain of sand based on its end-user value. Or it can be hard, normal, or easy, depending on the effort required.
The challenge is that no matter how you document requirements or estimate, nobody knows exactly how long each rock, pebble, or grain will take. There are ways to reduce risk: timeboxing, breaking down tasks, using historical data to forecast, constantly following up with engineers, splitting work between teams so features aren’t derailed by bugs and incidents, preliminary analysis, etc. But these don’t solve the core problem — we don’t know how long work will take. That’s the harsh reality of software development.
Originally published on Medium.com