The Fundamentals of Roadmapping

We are in an era of Objectives & Key Results (OKRs) and Key Performance Indicators (KPIs); tools companies use to track and measure their progress and ensure they are on track to reach strategic goals. In scaling startups, CEOs and co-founders have mixed feelings about delegating tasks they once owned to new layers of management. Some tasks, like perhaps managing the books to a new head of finance, they are eager to let go of, and some, like product decisions, can cause a lot of angst. In these times of transition, it’s not uncommon to implement OKRs/KPIs as a way to get comfortable with handing off these responsibilities. As management layers are added, there is a natural fear of no longer being close to the detail, of wondering whether a team can execute as well without a founder/top leader engaged in the day-to-day. I often hear CEOs/Founders of scaling companies ask how they will know if things are working if they are no longer in the weeds. These leaders want to trust their team and worry about micromanaging, but they also want accountability and the ability to track progress.

Measuring performance and holding leaders accountable is indeed important, but what’s often missing is the holistic view of where the company is going and an organization-wide understanding of how it will reach its goals. Before setting those metrics, leaders must be clear about the True North for the business — the compass of your company’s identity and growth direction — and set a near-term vision with a roadmap to get there.

The 30K Foot View

Anyone that asks what your company’s 3–5 year roadmap looks like is clueless about how businesses — at any stage — really work. With constant innovation, new market entrants and potential black swans like a global pandemic, the best a leader can do is set a 12–18 month strategic plan that is directionally aligned with the company’s true north. That plan should be broken down by quarter with the assumption that the degree of confidence in achieving goals within each quarter will decline over time. You cannot predict the future, but you can build within a set of assumptions. Assumptions should be articulated for each goal as a means to establish confidence levels.

Here’s a framework for thinking about the high level view of your company’s roadmap:

High-level Roadmap Framework © Julia Austin 2020

The true north (or mission) statement should be at the highest level, a guiding principle of the impact your company is committed to making for the long term. When I was CTO at DigitalOcean, we coined the true north statement “To Empower Developers To Build Great Software”. This gave us focus on our target persona (developers) and latitude to evolve as needed to achieve that mission. While we were (and they still are) a cloud company, this statement said no matter how we evolved, markets change, etc. we would remain focused on what’s needed for developers to build great software. Google’s statement is “to organize the world’s information and make it universally accessible and useful.” Again, the focus is on the impact — the world’s information being accessible — not how the company delivers on that mission.

The 12–18 month vision statement should be a clear focus on near-term impacts. This may be to achieve a certain level of market adoption or to have a core set of offerings viewed as table stakes for the target audience. It could be the launch of a new product or service or a major financial metric like reaching Free Cash Flow.

Quarterly OKRs/KPIs should be brief (no more than 2–3 major goals), achievable, but with some amount of stretch. In other words, if you were using the traffic light rating system (red, yellow, green) not all of them will be “green” per quarter. More info here. Beware of over-adjusting OKRs every quarter — while they will definitely evolve, especially if the process is new to an organization, there can be a temptation to focus on changing the objectives vs. adjusting KPIs or accepting that the goals simply can’t be met for other reasons (poor leadership, systemic issues, market changes) which should be addressed outside of the rating process.

Expect each team across the organization to cascade their operational roadmaps from these strategic foci. Operational roadmaps should identify key initiatives and milestones. Some milestones may be a sum of parts (as in the Engineering roadmap below) and some may be more linear and timeline driven as the Operations and GTM roadmaps show below. Of course, each initiative can be broken down even further per team (see next section); that’s up to each team to decide how to manage from there. However this high level format is the right level of detail for broader communication across the organization and perhaps with your board or even your customers.

Strategic Roadmap Example © Julia Austin 2020

The Process

I encourage a six-quarter rolling approach whereby each quarter the leadership team:

• rates and reflects on last quarter’s results;
• reviews upcoming quarterly goals;
• adjusts assumptions and factors in any new information (market shifts, product/revenue changes, etc.) for the next 6th quarter;
• communicates the updated company plan across the organization; and
• has each team create a tactical roadmap that lines up with the quarterly goals.

Below are representations of tactical roadmaps I’ve seen used in two very different organizations. In the first example, the product team and key stakeholders (sales, support and finance leads) review current priorities and drag and drop efforts according to their complexity and priority relative to company goals. They use a product like Mural to collaborate electronically (both when in-person and remotely). In the second example, a simple spreadsheet is used, projects are t-shirt sized using standard scrum methods, and there are links to each project’s details (in apps like Jira or Trello) for more information about relevant epics and user stories. PMs meet with engineering leaders each month to review and adjust as needed. In all cases, the details of each major initiative includes tie-backs to OKRs/KPIs. If they can’t be tied back, and measured, they should not be on the roadmap!

Example One

Example Two

Considerations For Very Early Stage Companies — Pre-Product Market Fit

• If your company is very early stage, expect to pivot the vision and the roadmap a lot as you learn and grow. Create guiding principles for when and how you would adjust a True North and/or Vision Statement. What factors must be true? What assumptions are you making about the market and/or target persona that may prove wrong or different than what was expected? Will you lean into these new findings and shift the direction of the business or keep testing those assumptions in different ways to learn more? Even the earliest staged companies should have a true north as they get started.
• Avoid peanut buttering! One of my favorite terms, this suggests spreading many things across a broad surface vs. being focused on a few key initiatives. It is scary — especially for early stage companies — to commit to only 1–2 things when it’s so unclear whether either/both will be a success and there are so many other things to try. However, by spreading limited resources across too many things, it’s more likely nothing of substance will get done, or things will move too slowly OR each thing will be done with poor quality while possibly burning out your team. Pick those 1–2 focus areas and set time-boxed milestones that will drive next steps or a change in direction. For example, “we must reach 20–30% conversion rate with the current MVP over the next two quarters or shift to the other product idea.” Commit to these milestones and agree how close you’d need to be to reaching that goal to keep moving forward vs. cutting bait and moving on.

Considerations For Companies With Product Market Fit

• Appoint a roadmap owner who can oversee the process across the organization. This is typically a senior product manager/head of product or Chief of Staff who is empowered to drive decisions and prioritize based on the 12–18 month vision. This role may be supported by a program/project manager who maintains the details in whichever tool or platform you use (e.g., updates the spreadsheet, inputs changes into Trello, etc.)
• Be mindful of how much time your team is spending on roadmapping and the measurement process. If it’s taking more than a few hours per quarter to discuss, update and communicate the roadmap and OKRs, it’s costing your company far too much time and money. This process supports productivity, it doesn’t become the work itself! If it’s taking up too much time, it’s likely the goals and measures are far too detailed and/or there are too many people involved in the process.
• Establish Rules of Engagement (ROE) for times when an opportunity or challenge may disrupt the roadmap. For example, what size/nature of a new customer opportunity would disrupt the roadmap? Can it only be for initiatives that were already on the roadmap, but further out? Will the sales team have points they can “spend” per quarter to reprioritize something? What about a major bug/performance issue? How bad would they have to be to disrupt the current plan? Once the ROE are set, these too should be managed by the roadmap owner. If the ROE are not adhered to, they’re useless, so only have a few and keep them simple. E.g., unless a new customer could grow revenue by x% and what they need is already on the roadmap, we won’t do it. OR if a bug is creating more than x% churn or denying service to a critical mass of customers, it’ll be fixed in accordance with the roadmap.
• Prioritize the backlog and tech debt as part of the process. These are just as important as new features and the longer they are put off, the harder they will be to schedule and get done. Set aside anywhere from 3–10% of resource allocation dedicated to these efforts. It largely depends on how severe issues are, whether upcoming roadmap initiatives have dependencies on these issues and/or how long they have been festering. It can be useful to “age up” backlog/debt items to raise their priority.

A few finer points on this topic:

• If a new request or critical issue bumps something else, always communicate the tradeoff(s) made and the positive or negative impact they will have on OKRs/KPIs.
• Developers hate roadmap thrash! So try not to disrupt it too often.
• Remember, for projects already underway, a reprioritization is not a 1:1 swap — there will be a J-curve in productivity each time a team has to stop something, start something new, and return to the old project later.

Conclusion

There is no one best way to do the roadmapping process. How you lead, the type of product you build, organizational structure and culture all come into play to determine what will work best for your company. Having a roadmap process will improve the prioritization process and create alignment among teams, will provide transparency across the organization and should give leaders (including your board) the right level of visibility to ensure the work is getting done. Don’t create a process just for the sake of process or implement OKRs just because someone told you that’s what you’re supposed to do. Be thoughtful and implement whatever process works best for your company.

Do you have other suggestions on how to run a great roadmapping process? Please share in the comments!