Why your product roadmap is failing - Part 1

The first secret sauce to getting it right - Estimations

Most product teams spend weeks working on their roadmap for the quarter. After countless hours of white-boarding, prioritization, discussions, brainstorming, alignment exercises, and whatnot, they end up with a clear, goal-oriented roadmap that has all the elements of growth and measurable success. As the product owner, you beam with pride, and the team is convinced that this is the quarter that they’re going to drive that elusive hockey-stick growth. After all, the plan and roadmap has never felt so clear.

Fast forward to three months later - PMs are juggling with multiple projects all in different stages of execution, there is a bottleneck in the pipeline, you don’t have enough engineers to see all your projects through, and while you were able to release that big, shiny feature, your users are still not adopting it as fast as you thought and it hasn’t moved the needle on the metric you were targeting.

Sound familiar?

So where did we lose the plot? We had a clear roadmap, so why didn’t it all come together? We’ve all been there, and after years of planning roadmaps, I’ve learned that the trick to the sauce is not in the planning step, but rather what comes right after it - the estimations and sequencing. That’s the step that puts your entire roadmap into perspective and takes it from theory to something that can be put into direct practice.

I’ll go so far as to say that your roadmapping exercise is, in fact, incomplete if it stops before estimations. 

Why is that important? Let’s take a step back to recall how you came up with the roadmap. Regardless of the exact process you followed (or if you followed what I highlighted here in the two-part series about roadmapping), in essence it’s likely that you’ve zeroed in on a set of goals that you think you need to achieve to call this quarter a success, and you also have a list of corresponding projects that will help you get there. However, while the destination sounds good, you still haven’t mapped out how you’re going to get there. What does the journey through the quarter look like? Do you have all the necessary resources in place? How are you going to sequence the projects? When do you start each project and how long will it take to execute? Will you be able to take up all the projects within the 12 weeks of the quarter? 

Therefore, to have a successful quarter - and I define success for a PM by not just the number of projects released, but actual goals achieved - you need to include estimations and sequencing in your quarter planning cycle. In this first blog of this 2-part series, we look at estimations a little more in detail.


Simply put, estimations are a measure of how much time it would take for a single developer to develop a given feature, measured in days (or hours, if you want to get really precise).

By definition, estimations are forward looking and are done before you start working on the said feature.

Ok, if you’re a product manager and if you’re the one coming up with estimations for projects instead of your engineering team - STOP RIGHT NOW. You have no business coming up with estimates, unless you’re the one literally coding the feature. Being a PM is a tremendously people-oriented job, and one of the most empowering things you can do for your engineering teams is to let them propose how much effort developing a feature would take them.

With that out of the way, let’s get down to it. Here is the simple framework that I follow to get estimates from my engineering teams, and it has served me pretty well.

  1. Write down the list of executable projects that you want to target for the quarter. These are the exact list of features or deliverables that you want to work on. If you use a planning framework such as OKRs, make sure to translate each key result into actual initiatives/projects that will be driving it. A simple Google Sheet that your team can collaborate on can serve this purpose well.

  2. Against each project, write down the scope of the project. You may not have detailed product specs ready or have a deep understanding of the details of the project - that’s ok. Just write down the summary of the project in as much detail as possible at this stage, so that everyone in the team gets a good idea of the story.

  3. Write down the priority of each of the projects from a business perspective - a simple low, medium, high would do. This is important to do as early as possible so that everybody is clear on the high priority projects of the quarter, right from the word go. Don’t be surprised if you see the stories that you had marked as “High” being debated the most and receive the most accurate estimates.

  4. Pull the entire execution team - PMs, designers, developers, testers, project managers - into a room (or a Zoom), and walk them through each of the projects. Talk at length about what you wrote down in step #2 and make sure everybody understands the scope and description of each of the projects. This is a very important step, so take as much time as you need.

  5. The ASK - at the end of the discussion, ask your developers and testers to take a day, discuss internally, and come back with an estimate of each of the stories. Use any format your team is comfortable with - at this stage, Agile’s popular T-shirt size estimates work well too. Your goal as a product owner is to end up with a fair understanding of how much effort developing a feature will take, in days, once it leaves the product and design garage.

  6. Once the estimations are done, reconvene and ask the engineering team to walk you through each of them. Feel free to debate, argue, clarify each estimate, but ultimately, make sure everybody is aligned on whatever is written on that document.

At the end of this exercise, you should end up with a common understanding of how many days it would take each of your engineering functions - backend developers, frontend developers and testers - to execute a project if a single developer was working on it. Add it all up for each function, add a 30% buffer for good measure, and divide by the number of members on that team - you will already have a fair idea if you are overcommitting or under-committing in the quarter.

We are halfway there, and it already feels like we have a better idea of how the quarter is going to pan out, isn’t it? In the next post, we talk about the second phase of nailing the perfect roadmap - sequencing.