Roadmapping and Quarterly Planning for Pros

The goal of this exercise is to accurately, transparently, and consistently allow an organization to decide what it wants to do, when, and at what cost. And to do that in as sustainable, low-overhead and low-stress a way as is feasible while still meeting that goal.

I’ve rolled out this process, or something like it, across more than a dozen organizations. Shockingly few organizations, no matter if they are big or if they are small, have any process whatsoever for deciding “what should we do, by whom, in what order”. In fact, of all the organizations that I’ve ever worked for or have had as clients, exactly one has ever not needed this process to be rolled out. One. Across dozens of organizations from startups to Fortune 100 companies. One.

The trick here isn’t to roll out some ponderous, enterprisy process. The trick is to answer, as quickly as possible, with as little overhead as possible, in as coordinated and trasparent a way as possible, the extremely simple question: “what should we be doing next, and what should we be doing after that?”

Here’s what we’re going to do.

Over many years, I have developed an approach for answering this question. Sometimes its been too complicated, which has lead to confusion, frustration and excessive overhead for too low value. Sometimes, I’ve tried to cut it too short, which has lead to confusion, frustration, rework, and inefficient execution. Finally, I’m pretty sure I’ve landed on the goldilocks approach: add more process, and it will be too much. Take any away, no matter how “overly processy” if feels, and the result will be ineffecive.

Here’s what we’re going to do: –Have coherent, empowered units of people decide what they want to do, in what order, totally independent of the capacity of the resources that might do them –Blend the lists of things from each unit into one uber-list, in holistic, organization-wide priority order –Estimate how big the things in the consolidated list are (the demand) –Estimate how many person-weeks of different types of people (the capacity) we have to get things done –Distribute the demand across the appropriate capacity until we run out of capacity

It’s that simple, actually. At least in concept. But that’s deceptive. Actually, lots of things can go wrong and it’s important to manage your expectations.

Assign pods/teams/focus areas based on

Goal of this stage: clearly identify the deciders and what they are responsible for deciding among.

Coherence: do they self-identify as a unit and hold together Contribution: do they have an identifiable business impact and accountability, all by themselves, that nobody else shares Empowerment: can they independently make priority decisions that stick, without consulting anyone outside the group Focus: Is each individual largely focused on only this group’s needs, and not spread out across a bunch of groups Tied together: they all depend on the same set of resources to actually get things done and so have to figure out how to share them

Make these groups as large as you can while still holding the above things true. Ideally, you have somewhere between one and five of these groups sharing any given pool of resources. If you have more, then you are unlikely to be successful. And you have identified an organizational dysfunction that should probably be addressed.

Push these groups as far down the organizational tree as you can, but don’t force it. If it turns out that the only group of people who fit these qualities are the executive team, then so be it. And, also, off to the side, ask yourself if you’ve got a larger organizational problem regarding delegation that needs to be addressed.

These groups don’t necessarily need to have engineers in them. They do need to have product people in them, but they don’t necessarily need to have the head of product in them. They also don’t necessarily need to encompass the entire organization. They only need to be the part of the organization that is both empowered and responsible for setting priority and is accountable for producing material business outcomes. They’re the deciders, not necessarily the doers.

If you have a hard time identifying teams that fit these criteria, then you have a bigger problem and any process you try to bring in will be starting 100 meters behind the starting line and will likely fail, no matter how good the process, otherwise, is. Address this problem first, if you can. Some antipatterns that tend to make this difficult include:

–The CEO/CTO/Head of Product/whatever is the only one with real decision making power and has not delegated properly, so everyone has to check with them for every decision –There is an active power struggle among one or more “deciders” that actively disrupts creating consensus –The actual product or business strategy is unclear, so nobody knows how to benchmark their priorities against it –A material number of people are spread too thinly across too many unrelated responsibilities –The RACI matrix for everything is too vague or has never been defined –Decisions, generally, don’t tend to stick unless “everyone” has weighed in. Too many people have veto power –Too many self-identified groups don’t actually have a direct line to the business value they create –Overshared resource pool that needs to be split up –One or more “loud voices” tend to sideswipe things late in the game and need to be put in their place

For more information, see our deeper explainer on identifying and assigning teams to own roadmaps.

Have them identify projects

Goal of this stage: get out of hand-waving, crisis-of-the-day land and clearly identify what needs to be done. Develop a strategic vision that’s independent of resource constraints

Size: between N person weeks and 6*N person weeks Scope: with enough of a description that most people would know what it is and what it isn’t Extent: it’s ok if the project requires other teams to execute

Of all these things, getting the size right can be the most challenging. It’s too early in the process to have even good educated guesses about how “big” these things are in calendar terms. Nonetheless, it’s also critically important that you’re dealing with projects are are all “roughly the same size” and “big enough to be strategic while small enough be digestible”. I’ve tried, oh how I’ve tried, to get people to resist the urge to think in terms of calendar time to define a size of a project and to instead work with the guidance of “roughly the same size and big enough to be strategic while small enough to be digestible”. And I’ve failed. People simply aren’t programmed to think that way.

So, instead, it’s best that you surrender and offer up the false precision of “please size the projects somewhere between N person weeks and 6*N person weeks” where N is the size of your average sprint. So, if you have 2-week sprints, then say “please size the projects somewhere between 2 person weeks and 12 person weeks”. “But, Tim, how do I know how many weeks a project is if I haven’t even really defined it yet?” you might ask. Well, you don’t. That’s what I meant by “offer up false precision”. The best you can do is let the asker decide for themselves what a “2-person-week project” is just based on their gut and move on. Will they be wrong sometimes? You bet your ass they will. Will any two given people have wildy different ideas of what can be done in 2 weeks? Also yes. This will all be ironed out later, so just deal with it for now. Try not to get stuck here. It’s an unresolvable tarpit.

If they’ve got a bunch of small stuff that’s less than the lower threshold, then encourage people to bundle those things with other small things and make a block of stuff, ideally with a coherent theme (see here). At the absolute worst case, you can always create one or more time-boxed blocks called “tactical queue block #N” see (here) for what a “tactical queue” is. Alternatively, you can designate sticky resources that just work down the tactical queue off to the side and aren’t counted as resource in this strategic process. Either works equally well and has various tradeoffs.

For more information, see our deeper explainer on identifying projects.

Gather tech debt projects

Goal of this stage: create transparency around tech overhead that doesn’t necessarily align to business outcomes

Given the way we’ve structured these decider groups, it won’t necessarily be the case that the technical owners of each of your distinct software systems is represented in any of them. Nonetheless, each of these technical owners have various tech-driven initiatives they need to get done. Some of them are tech debt to clean up. Some of them are the necessary upgrades and other migrations that just have to happen with living, breathing software. Some of them address scalability thresholds that their systems have crossed because your business have been so wildly successful.

Most likely, none of these initiatives will fit nicely into any of your business-oriented groups. It’s very likely that nobody outside that engineering team will understand what they are or how to advocate for them. But they do still need to get done. They’re not going away. So, you really only have three choices in addressing them:

1) pretend they don’t exist and eventually go out of business in a supernova of system failure drama 2) give your system owners a fixed slush fund of their own resource, unallocated to this strategic process, that they can use as they see fit 3) gather their projects into this process and have them advocate for them alongside everything else just like any other project

Option 1 is obviously not a good option, even though it is the one that most businesses slouch into anyway, unless forced to do otherwise. Option 2 definitely works, but it isn’t, personally, my first choice because it isn’t transparent enough and tends to breed mistrust between “the business” and the engineering team. Option 3 is a delightful choice, in my opinion, though it does tend to be frustrating and stressful for those system owners and they will likely need help in navigating it. What’s most important, above all, is that you consistently stick to one or the other of these approaches, and that every team does it the same way.

To persue Option 3, have each system owner identify and prioritize tech debt projects to feed into the process alongside everyone else, as if they were their own group. Alternatively, designate one, single, existing business aligned group that is “theirs” and have that group prioritize and advocate for their projects. Either works pretty well, depending on the particulars and personalities involved.

The persue Option 2, simply decide what you want the percentage allocation to be, and hold out that allocation from that group’s capacity in the last step of this process. Boom, you’re done.

For more information, see our deeper explainer on gathering tech debt.

Prioritize

Goal of this stage: force some hard choices, but without having to synchronize across the org or do real estimation

In waves or batches (now, next, soon, later, unlikely) 5 now 10 next 20 soon 40 later everything else: unlikely even saying something is “unlikely” is useful. It prompts conversation and allows for otehrs who wanted that thing to know they need to make alternate plans

For more information, see our deeper explainer on prioritizing projects without knowing their size.

Blend

Goal of this stage: force more hard choices. Synchronize priority across the org (or at least across this resource pool)

Have one person from each team, plus the owner of each distinct system (to speak to tech debt priority), plus the heads of product, GTM, and engineering represent their priorities in a Hunger Games session to make a combined now, next, soon, later. Make it very, very clear to people that this is their last change to argue priority. If there are tough conversations to have, they must be had now. Everything past this point is going to just be science and math.

Stop when, even though you haven’t t-shirt sized anything yet, it’s blindingly obvious that nothing you add further is going to be done any time in the next ~4 planning periods, anyway.

This should be bloody. If there isn’t a lot of argument and consternation, then you’re doing it wrong and should seriously examine why.

For more information, see our deeper explainer on blending priorities globally.

First Cut

Goal of this stage: reduce unnecessary work later in the process. Sound early-warning alarms on misalignment on priorities.

The rest of the process is expensive and time consuming. So make an attempt to only do it for stuff that has some chance of making the cut. Keep it stone simple: look at how many project line items you completed in the last two planning periods (i.e. quarters) and keep that many, plus, say, 50%, if you like, to carry forward. Everything else gets dropped, for now

Sketch and t-shirt size

Goal of this stage: force more hard choices. Surface confusion and misalignment and resolve it. Create information needed for the next step. Reduce (but not eliminate) uncertainty.

Don’t worry about nailing all the requirements. But do identify and, ideally, commit to a perspective on any obvious dogwaggers.

For more information, see our deeper explainer on t-shirt sizing projects without spending an eternity doing so.

Second Cut

Goal of this stage: reduce unnecessary work later in the process. Sound early-warning alarms on misalignment on priorities.

Take the number of person weeks you have available and divide that by the list of projects, in priority order, until you are roughly 25% over capacity.

Take stock and socialize

Goal of this stage: Sound early-warning alarms on misalignment on priorities or unreasonable expectations around capacity. Force org-wide commitment to what we definitely aren’t doing.

If you have a really high trust environment, or risk tollerant environment, or your priorities change so often that investing more effort to gain certainty probably isn’t worth it, then stop here. But know that you can’t hold anyone accountable to hitting this project list if you stop here. That doesn’t mean this exercise was not valuable! In organizations I’ve been a part of that only get this far, we’ve seen tremendous value, already, simply from the clarity, transparency and visibility that this process brings.

Why can’t you expect commitment? What you have so far is better than wild guessing, for sure, but also contains so much uncertainty that it’s impossible to make a real commitment to. You can still improve the odds, though, that you actually do hit this plan, such as it is, even though it’s bursting with uncertainty. See (here) for strategies for managing to this kind of plan, anyway (e.g. timeboxing, moving risk to the front, checkin milestones)

It’s really important that you get organization-wide commitment to the prioritization (and the likely cut line) before you go to the next step. Do not proceed until you do, if you can help it. You need to have the hard conversations of “hey, so, we’re still running the numbers, but it looks very likely that XYZ thing that you’re really passionate about isn’t going to make the cut this quarter. Is that a problem? If so, what would you trade off for it from this list of things? Nothing? Well, that’s a problem then. Let’s talk about it.”

If you fail to do this step well, the following steps will absolutely suffer.

For more information, see our deeper explainer on taking stock and socializing a roadmap even with imperfect information.

Refine, estimate

Goal of this stage: generate the information necessary to complete the next step. Reduce uncertainty.

Doing this right is very time consuming. So, it’s really useful, for efficiency sake alone, that you’ve done a good job of cutting things and having the resulting difficult tradeoff conversations before you get to this point, not after or during. All of the big decisions should have been made already before you get here, or you will be wasting a collosal amount of time. This should be an exercise in science, not politics.

Expect this step to take a long time. If you are cold-starting this process (i.e. you don’t have a head start from stuff you refined in the previous planning cycle that didn’t quite make the cut) then it’s very likely this step will take longer than you have, actually, to do. You might need to cut it short and try again next cycle for the sake of getting down to business.

This is the place where you really make the tradeoffs around time and scope. You have to identify the project’s goals. They must be SMART goals. The Product team and the Engineering team should be collaborating intensely to define what needs to be done and roughly how it will be done. Different approaches and their plusses and minuses should be surfaced, so the team can commit to one. Dogwaggers should be identified and comitted to. If you don’t do these things, then that’s potentially still ok, It’s the reality of life in business. But it also means you can’t expect a commitment to delivery. That’s just the reality of life, too.

For more information, see our deeper explainer on refining and estimating projects in detail now that you’ve created a short enough short list.

Characterize and assign resources, then bless and commit

Goal of this stage: Force org-wide commitment to what we definitely are doing. Get everything ready to actually start executing.

This is the first time you finally marry what you want to do to who is going to do it, for realsies. This is where individual career growth, the company’s goals, the shape of your hiring, people’s vacations, people’s individual variability in delivery all come in to bear. This is the part people tend to try to skip directly to without having done the other stuff first, usually with disasterous results. If you’ve made it this far then, finally, you should have a plan that your engineering team actually commits to, and you should feel entitled to hold them to that commitment. No more excuses.

For more information, see our deeper explainer on characterizing and assigning resources to projects and our deeper explainer on blessing and committing to a roadmap.

Variations

I’ve never actually done this process exactly as describe here in any given organization. What I’ve described here is a hybrid of the things I’ve actually done. You can, and, actually, absolutely should, modify it to fit the needs and realities of where you are. Some specific examples follow.

For more information, see our deeper explainer on variations to this roadmapping approach to fit different realities at different organizations.

Timebox instead of estimate

When I was at SwingLeft, we had this interesting challenge that I’ve never had anywhere else. I called it “the mother of all hard deadlines” which is to say, the 2020 election. Nothing, and I mean nothing, was going to move that date. It was just reality: anything we didn’t get done before November 2020, we might as well not do. So, rather than approach this as “this is what we want to do, how long will it take?” I approached it as “how many reasonably-sized timeslots do we have, and what do we want to put in them?”

Single team

In places that are small enough, you can get away with just having a single team, which means there’s no blending step. All the

Low trust, low commitment, high expectation

Doing this process successfully requires having the true decision makers materially involved and bought in. Sometimes, you don’t really work in that kind of environment. Sometimes the true decision makers truly have an attitude of “I want what I want, I don’t want to hear about conflicting priorities, I don’t want to participate in the process of resolving those conflicts, I just want you to deliver.”

Most people think they work in this environment, but they are usually, actually wrong. Don’t reach for that explanation lightly. It’s a lazy or low-conflict person’s out. Most of the time, once you do the important and painful work of rolling this out, what felt like that attitude will actually turn out to be stressed out people with low information and low trust doing stressed out things. This process actually fixes this apparent problem, most of the time. So you need to at least try. In fact, more than once, I have seen the rollout of this process lead, at least partially, to the firing of these kinds of executives, due to the visibility this process provides and the way it highlights that executive’s dysfunctional behavior. And that is a win, for you.

But if you really, really try and it still doesn’t work, then a) update your resume and start looking for a new job (seriously) and, in the mean time, b) focus on the transparency part and let go of the prioritization and estimation part. Broadcast what you are planning to do, in what order, and make sure that changes to that order, when they are foisted on you from the outside, are as visible (and tracable to their source) as possible, so that that low-trust executive can go yell at that person instead of at you.