Overview | Roadmapping and Quarterly Planning for Pros

So you want to know the most effective, least labor intensive way to generate a solid product and engineering roadmap? We’ve got you covered. In fact, this is one of the services we offer here at Pollen. But you don’t even need us to walk you through it, if you’re feeling frisky. Just follow this process and it’s literally the same thing as what we’d guide you through, anyway. Still want help after reading? Get in touch at info@pollen.io.

First, let’s start by managing your expectations. If you’ve never done this before, it’s going to be bumpy, it’s going to take a few iterations, and it’s going to highlight previously-unseen inefficiency in your organization. That’s ok! It’s all part of the process. The link above helps you prepare for what might come up.

With expectations set, it’s time to identify and assign teams to own roadmaps. These aren’t, necessarily, the same as the teams who will execute the roadmap. The trick here is to find the smallest number of the smallest teams you can, while still empowering them to make decisions that stick. It’s harder than it sounds. And it’s key to getting this right.

Once you have teams, then they need to actually identify projects. There’s a Goldilocks-like art to this: too small, and you’re buried basically managing Jira tasks. Too big, and you have no idea what they are and when they might be delivered. Get them just right, though, and you’ve landed one of the chief benefits of good roadmap planning: allowing executives to trade off meaningful priorities to meet business goals.

Roadmapping is, rightfully so, very business focused. We need to make sure we’re tracing the work we do to some business goal. But, software is a living, breathing animal and it needs to be continuously fed by paying down its accumulated tech debt. Let’s make sure we surface the cost of that tech debut within our roadmapping proces, instead of off to the side, so that everyone is bought into paying it down.

At this point, we’ve probably got dozens to hundreds of projects sketched out. Seriously. And, even though we don’t yet know how big they are (because we haven’t estimated them yet), anyone with eyes can say they represent many, many multiples more work that we can accomplish in a few quarters. So, let’s save ourselves some effort by prioritizing those projects team-by-team in some semi-formal way, so that we’re not carrying them all forward through the rest of the process.

Now, each team has set its own priorities. The hard reality, though, is that all those teams share the same set of resources (i.e. developers). So, it’s time to start blending priorities globally so that we can further trim what we have to carry forward to the estimation phase. If you’re a super small company with only one identified team then, lucky you! You can skip this step!

Estimating the size of projects is quite an expensive activity, actually, so, thusfar, we’ve avoided doing it until we trimmed our list of projects to a managable size. Well, we can’t wait any longer. It’s time to t-shirt size the surviving projects without spending an eternity doing so. We want to do this as quickly as we can, while still having it be some defensible, better-than-a-guess, estimate. I’ve got the way.

At this point, we’ve got a sense of priority and we’ve got an educated guess on size, so, even without doing the rest of the detailed estimation and resource planning, it’s time to take stock and socialize the roadmap. The rest of this process is much more expensive, so it would be a shame if there are some deal-killers in there, from an executive perspective, that will just get overridden later, anyway.

Ok, we’ve now had some hard conversations about what’s likely in and what’s probably out. Now it’s time to make real commitments that we hold our development teams to. That’s right, it’s time to really invest in refining and estimating projects in detail so that we can truly commit to their delivery dates. This is expensive and hard. Good thing we did all that work to cull the list before here!

Only now, given we’ve refined the projects and estimated their size, can we proceed with characterizing and assigning resources to projects. This is where real people get mapped to actual projects. This is where we consider who has what skills, who is fast and who is slow, and who’s on vacation next quarter.

Ok, the planning is done and it’s time to deliver. It’s time to commit. Committing to a roadmap is a real step that’s worthy of its own process, so that everyone knows what’s in and what’s out and there are no hard feelings later. Good thing we have a whole process around blessing and committing to a roadmap.