Boulders to Stones to Pebbles
Decompose objectives into workable chunks
Product managers don’t move mountains. They neither pick the mountain to move nor move the mountain that’s picked. Their roles are necessarily smaller than that. A PM is rarely in the first round of hiring for an early-stage startup and is only staffed once a company knows its mission.
Suppose an ambitious company wants to move Mount Rainier from Washington to Florida. This enterprise is the company’s purpose for existence and will give it direction for decades. Product managers carry the mission of deconstructing Mount Rainier boulder by boulder and relocating it to Miami.
An essential skill for product managers is problem decomposition: going from boulders to stones to pebbles.
Boulders
Boulders are initiatives that ultimately align with the company's mission. In our silly example, an initiative to transport one boulder of Mount Rainier to Florida will be 100% strategic. Leaders at the VP or director level decide which boulder to move by evaluating the initiative's impact and its high-level cost. Like a new product launch, boulders can take multiple quarters to move and involve several teams.
The ripple effects of boulder decisions are enormous. If dropped into a body of water, a boulder will create waves—great for surfers but potentially disastrous to homes near the beach. As such, decisions on which boulders to select need careful review and critical examination.
“Great is the enemy of the good” doesn’t apply here. If there isn’t a strong initiative, the job transforms into finding the right one. The focus of boulder-level decisions is on impact and strategic direction. Product VPs and directors are accountable, whereas individual contributors are consulted and eventually responsible for moving the chosen boulder.
Stones
Stones are deconstructed boulders, epic-level projects that support an initiative. Product managers spend most of their time here, as they are accountable for selecting and executing the stones to work on. As such, conversations at the stone level are about 50% strategic and 50% tactical.
Specs and designs are needed for stones because various teams must align on the priority of the given features. Stones could include the required infrastructure, the implementation of the feature itself, and the monitoring and alerting needed to support post-release. Each stone should take about a month (i.e., two to three sprints) to complete.
At the stone level, PMs focus on ROI to ensure the effort justifies the value and that all stone requirements tie back to its associated boulder. Capacity-first planning can help prevent scope creep.
Pebbles
Pebbles are deconstructed stones, story-level efforts that support an epic. They are 100% tactical and related to the specific details of execution. The product manager should spend minimal time on overhead for these work items and avoid force-fitting requirements into dumb templates. Instead, PMs should write clear, specific, measurable acceptance criteria and let engineering own the how.
PMs should be involved and aware of each pebble to verify that it builds toward the desired stone, but too much involvement is usually an antipattern. Engineers may grind a pebble into even smaller tasks, like sand. PMs should not play with the sand because they must focus on throughput and holding teams accountable to a high say-do ratio.
Dynamite or a Pickaxe?
Although I mapped boulders to initiatives, stones to epics, and pebbles to stories, this metaphor is not tightly coupled to one decomposition. Based on a PM’s level or the company dynamics, a boulder could be an epic and a pebble a task. The mapping doesn’t matter, but thinking about boulders, stones, and pebbles can help frame discussions and identify problems.
A boulder-level discussion is needed if a team is confused about the why of a project or doesn’t buy the stated value of an initiative. In other words, where should we place the dynamite? There’s no point in discussing pebble-level details if stakeholders don’t buy into the goals. Conversely, arguing about edge cases wastes time in a strategy discussion, as that’s a pebble conversation. Dynamite isn’t needed to extract a pebble, but a pickaxe is.
Product managers don’t move mountains, but they break mountains in the boulders, stones, and pebbles that make them moveable.
Action Items
Decompose one of your 2024 objectives into boulders, stones, and pebbles.
Nice metaphors. I like the idea of boulders to initiatives and stones to epics. I also like the image of dropping a boulder into a body of water - there surely are going to be waves. Trying to develop on your metaphor - what if the org tries to move the wrong boulder or that it’s moving the boulder to the wrong location e.g. Miami County Ohio instead of Miami FL. An initiative can go wrong in a myriad of ways and because it’s so massive the repercussions will be felt regardless of where it goes wrong. The other thing I’m picking up is that if an org is picking up a large boulder and everyone feels its weight it probably is a red flag by itself as you should not be picking up a boulder or a mound as is… there must be some tangible proximate objective in sight….