An imbalanced roadmap is a roadmap that is overinvested into a single type of approach to succeed. This is a dangerous kind of roadmap because it strikes a single strategy and, as a result, lives and dies by that strategy.
On the other hand, a balanced roadmap pursues multiple different strategies (often concurrently) in an attempt to improve its odds of succeeding. This article isn’t about the content of the roadmap but instead focuses on its form. Specifically, it focuses on the sizes of projects to be pursued and the quantity of each type.
This article makes the case for a more balanced roadmap-building strategy as well as how to pull it off.
Balancing the roadmap: rocks, pebbles and sand
You might have heard of the empty jar concept before, I’ll extend it here to fit the context of a product roadmap. Think of your roadmap as an empty jar that you have to fill. To fill it you have rocks, pebbles, and sand.
Rocks: These are your large projects, usually new features, revamping old ones, or tackling large tech debt projects. Usually around 1-3 months of work.
Pebbles: These are your midsized projects, usually small features, feature improvements, performance enhancements, and other mid-sized iterations. Usually around 2-3 weeks of work.
Sand: These are your small projects, usually smaller feature improvements, adjustments, and other small iterations. Usually around 1-1.5 weeks of work.
I draw the line at rocks as anything larger is very prone to failing. A project longer than 3 months to me is a mountain, and you might as well break it down into rocks, pebbles, and sand. What this model implies is also that everything, at the end of the day, is the same matter, just broken down to a size that maximizes your ability to extract value and get that thing done.
Given these elements, what you want to do is give yourself the opportunity to take big swings but derisk those projects with smaller projects and iterations. The big swing gets you the home run, but by pursuing some smaller projects, you’re still liable to get a single or double per plate appearance even when you miss a big swing.
Rocks
The roadmap can only really start with the anchor pieces and these anchor pieces are your rocks. If you start by filling the jar with sand and pebbles, you’ll quickly run out of room for the rocks. You’ll then find yourself emptying the jar to get the rocks in. If you put the rocks into the jar first, you can fill the remaining empty space with pebbles and sand.
Commit to your large projects first but make room for the rest. If you’re in a rock-obsessed culture, start by trying to create a commitment of only 50-65% of your time spent on rocks with the rest spread across pebbles and sand. The roadmap will need all three kinds of work to achieve balance just as the jar will need all three elements to be full.
Don’t fall into the rock trap:
There is often a lot of temptation to only try to fit rocks into the jar but you’ll find that the jar simply can’t fit too many rocks and that you’ll feel that a lot was left on the table.
In most people, there is a natural bias towards large-scale projects. There are a few reasons behind this:
Large-scale projects are generally easier to visualize, describe, and arrive at,
They don’t force you to make tradeoffs (when the scope is large enough, it’s always easy to just add another thing to make the project make more sense),
It’s easy to picture the outcome of a large-scale project and even easier to imagine the upside being transformative to the business.
Unfortunately, large projects cost a lot and take a long time to achieve (which reduces your ability to pursue other projects), given the scale, they require making lots of assumptions, which creates lots of room for error.
Large projects are worth pursuing but spending 12 months on 3-4 projects for most teams is a terrible idea as you’re really hoping those 3-4 things hit big and are giving yourself very little room for iteration. When you don’t hit big the downside can be catastrophic.
Pebbles and Sand:
You want to have a lot of room for sand and pebbles for a simple reason: The more shots you take, the higher the projected point total you’ll have. This doesn’t mean doing a bunch of crappy work, just that when all things are the same, you’re better off doing more than less. The easiest way to do this is to do more mid-to-small sized things.
This will require a big commitment from your organization: The entire system depends on you having room for small and mid-sized work. I’ve found this buy-in to be the single biggest challenge to roadmap building as most people, even when they say they want iteration, naturally only want large-scale projects. However, the sand and pebbles are what will give your product the ability to evolve quickly and react to opportunities and feedback and, as a result, are essential.
To make this even harder there is a really important commitment you’ll have to secure: when it comes to sand and pebbles, don’t lock those projects in ahead of time. You just want to commit to your rocks and get commitment to an open road of other things that will be picked from the highest-ranking items in the sand and pebble queues when the time comes. This allows you to be reactive and iterate based on what’s happening. By not planning ahead of time you allow yourself the flexibility to respond to today’s problems, not yesteryear’s ideas.
Sustainable jar-filling practices
Focus on the goal, not the implementation:
When someone reads the words that describe or identify your project remember that in those words is coded a set of ideas and that that set of ideas can be different from person to person. This can lead to disconnects about what the project is, what it’s trying to achieve, and its overall value. This disconnect hurts your ability to get projects done.
Try to define and identify your projects as much as you can by the goal, problem, or use case that it is setting out to address (vs by a code name or feature/implementation details). Ultimately, the team, through working on the project, may arrive at a completely different solution than what was imagined at the beginning of the project. By avoiding a focus on implementation, you give people the ability to hone in on the why of a project, not the how. This also ensures that anyone who comes upon that project has a higher likelihood of understanding the value it is looking to extract.
Create lots and lots of optionality:
The best way to improve your roadmap’s likelihood of success is to give yourself a lot of optionality with your investments. Optionality (in the roadmap-building context) is the ability to control investments gradually and to decide to quickly double down or cut back when things aren’t working.
To put this idea into the context of rocks, pebbles, and sand: Sand and pebbles give you a lot of optionality because the investment period is shorter, whereas rocks lock you into investments for longer.
You’ll find that it is much easier to do multiple pebble and sand projects back-to-back within a certain area than it is to do a rock and follow that up with sand and pebbles. This is because teams lose enthusiasm and momentum the longer they work on something. The joy of shipping is the one thing that can refuel teams in their pursuit of a long-term solution to a problem. As a result, roadmaps that pursue a lot of smaller-scaled iterations have the ability to stay committed to a problem for longer than roadmaps that are looking to solve the same problem with one large release.
More is more:
It’s better to do a single project at a time with quality than two with no quality. However, it’s often better to do 2 projects, each at 80% of their potential, than 1 project at 100% of its potential. Ultimately, you want to increase the volume of shipping until you hit a wall with your team’s ability to still deliver with quality. Sacrifice perfection (note perfection, NOT quality, as quality is essential) in lieu of velocity and volume. You can always improve upon things gradually but the door often closes if the investment proves to be too long.
The key to success with this strategy is to be able to tackle multiple items in parallel; the more concurrent initiatives your team can pursue in parallel, the easier it is to slot smaller-sized work. I try to have at minimum two independent projects in progress at all times for any given team; ultimately, this depends on the team, the team size, and your ability to support parallel work with quality.
Break things down:
You have to start by decomposing your roadmap before projects start. I’ve often found that most rocks are just collections of pebbles, and most pebbles can be made into sand. By tying a potential project to a size that best reflects the business’ appetite to solve that problem, you are starting projects with a healthy constraint. This honesty allows teams to accept the limitations of a project and work within those limitations. As a result, any change in the shape of a project is additive.
The more you shift things down a tier, the better your odds get as well. Often times downshifting is really just removing the parts of a project that have risk or are less proven and turning those into their own smaller stake endeavors.
Give yourself and the team the true constraints for a project and you’ll often find that this will improve the likelihood that that project gets picked up as well as the effectiveness with which a team can solve that particular problem.
The mental and emotional value of breaking things down:
Roadmaps composed of only large projects are naturally prone to lower vibrations. Large projects tend to be late, large projects tend to require cutting, large projects are left often unfulfilled in order to meet a release date. A large-project-oriented roadmap is a roadmap built through subtraction. You are constantly subtracting your way to a solution. Teams come up with complete solutions that are then cut, at best, early in the process and, at worst, close to a release. This is both inefficient as well as draining for teams. Editing is a key part of the process, and all editing is about sacrificing, but healthy editing feels like getting more for less, whereas unhealthy editing feels like being conned out of something.
In an environment that is more properly balanced, you can begin shifting towards an addition-based roadmap. Here, you’re often finding ways to start small, and over the course of a project, as a result of enthusiasm, discovery, or any other insight, you end up adding to your work. Addition is a highly enjoyable experience like receiving a gift; you did not expect it, but you’re glad it came your way. Editing in this context feels like trading for something better and it’s the most enjoyable kind of editing.
Adjust the bar to entry to match the investment:
Teams often apply consistent rules to every kind of project they pursue. These can be incredibly rigorous validation processes to gut-driven gamble-based approaches.
The problem with this is not in the process itself but in the fact that a one-size-fits-all mindset creates an implicit bias towards projects of a certain kind. For example, In a highly rigorous scoring culture, only rock projects are pursued because sand and pebble projects are often too fuzzy (or worse their perceived value is too low to warrant all the effort it takes to score).
To avoid this, I adjust the bar to entry for projects based on size:
Sand projects only require philosophical alignment and some key stakeholders liking the idea.
Pebble projects can also get through with just philosophical alignment and stakeholders liking the idea. However, we can ask for scoring for a pebble if there is contention.
Rock projects require scoring unless they play a key strategic role for the business or have a really high degree of belief from key stakeholders.
Ultimately, the bar you create is up to you, but the important idea is that you adjust it deliberately to incentivize the kind of balance you’re seeking.