top of page

Case Study: Building an Achievable and Realistic Product Roadmap in Tech

From FOMO to Focused Technical Product Roadmap

Here’s how I took a tech company with a planned annual roadmap that was 280% of their engineering capacity down to 80% capacity. Why? So they can actually achieve their most strategic projects, so their engineers have a fighting chance to achieve it, and so they can focus better. Here are the details of how we built a realistic product roadmap in three days with a cross-functional leadership team.

From FOMO Roadmap to Focused Roadmap


A tech company's ambitious roadmap was overwhelming its engineering team, with 189 projects planned for 90 engineers - 280% of their actual capacity.

Objective: Build a Realistic Product Roadmap

Streamline the roadmap to focus on strategic projects, ensure achievability, and optimize engineer productivity.


We implemented a multi-step filtering process to align projects with strategy, capacity, and value. Here is the short recap of what was achieved:

  1. Strategic Alignment Workshop:

    1. Reviewed top 20 strategic projects

    2. Projects mapped to 4 strategic pillars

    3. Non-aligned projects eliminated

    4. Outcome: 19 projects retained, 3 key focus areas identified

  2. Project Detail Review:

    1. Teams added priority, size estimates, and value alignment

    2. Result: 38 projects cut, reducing total to 150 projects

  3. Prioritization Workshop:

    1. Filter using MoSCoW prioritization (Must Have, Should Have, Could Have, Won't Have)

    2. Add Must Have Projects to a high-level gantt chart per team

    3. Add projects to a capacity chart with all engineering teams capacity and adjust projects, dates, and prioritization based on results

Detailed Approach, Product Roadmap Prioritization Workshop

We started out with 189 projects on the roadmap for 90 engineers for the year.

We put the projects through a series of filters to weed out what really must be done, what aligns with their goals, and what aligns with their capacity:

  1. We first did a workshop to clarify the strategy and go through the top 20 strategic projects. After a more in depth review of those, we cut out 1 super strategic project. Then selected the top 3 project focus areas of the year.

  2. Between this strategic workshop and the prioritization workshop, the teams added some project details about priority, t-shirt estimation, and value alignment. Just in that step, 38 were cut for not being strategically aligned. So now we’re down to 150.

  3. Next, we reviewed every single project in a series of filters. First, we put all the projects into Miro with the data from the teams and color coded by the leading team. The leaders added the projects into the 4 strategic pillars. Anything that didn’t fit got tossed out. 

  4. Next, we put those projects into a MoSCoW filter (Must Have, Should Have, Could Have, Won’t Have) and it showed the projects per leading team. Here’s what came out of the first pass:

  5. Must Have: 64

  6. Should Have: 52

  7. Could Have: 29

  8. Won’t Have: 5

  1. The first surprise came. We realized immediately that just the Must Haves visually were a lot for the teams to take on. To validate that, we started to only focus on the Must Haves and left the rest behind. 

  2. The team then added the projects to a gantt with the four quarters of the year as buckets. They added the super rough estimates just to see their teams fill up with capacity as a visual reference. (Note: of course these are not super accurate estimates, but rough guidance like “it will take 3 months” “it will take a year” just to see the relative size of everything).

  3. We then moved on to review the actual capacity of teams vs the 64 projects on a capacity table. We moved projects around and increased the capacity to start making a hiring plan, and came out with two proposals.

  4. The proposals showed the prioritized projects for the year and either completing all 64 Must Have, strategic projects with hiring, or cutting the projects even further to achieve this with the current headcount. 

  5. Since there was no hiring budget, they ended up with a few less projects, but a clear plan on how to execute the roadmap with the engineers they actually have.

Final Result

  1. Focused Prioritization: They ended up cutting 72% of their projects from their starting point of the original roadmap that was just made by Product Management. From 189 to 54 projects.

  2. Capacity True-Up: The original roadmap was unrealistic and required 280% of their capacity, and the new roadmap was at 80% of their capacity.

  3. The 20% Extra: They now have 20% capacity for everything else like tech debt, bugs, improvements, productivity, and a buffer for everything else and business as usual. 

Final Thoughts

If you want to build a roadmap that is agile and uses best practices, you can't just have your Product Managers build this in a vacuum. Not only do you need engineers to build it with them, you need strategy and the top leadership to identify where the strategic focus is so the projects align with that.

This is not the only time you should review your roadmap as well. This is your first product roadmap creation using a few days of focused time. After that, you should create a method to review, updates, and prune the projects as changes and results come in.

Let's Work Together

If you'd like to build a Realistic Roadmap with me in a workshop over 2-3 days, rather than months reach out to book a call.


bottom of page