Roadmapping a Quarter — Part 1

A Product Manager’s guide on getting it right

Planning a quarter is one of my favorite times in a year. It’s a rare opportunity to mentally pause (when else can a PM do that, amirite?), take a step back from the everyday madness to reassess the state of affairs, and truly gauge if you’re indeed headed in the right direction. Over time, I’ve come up with a simple framework that helps me quickly map out a quarter, while ensuring that I’ve accounted for all known parts of the business and input areas. It goes without saying that this has evolved over time after trying out various techniques, and might not be the best approach for all products and product teams, but I’m confident that it is a good contender.

In this 2-part series, I will outline a simple approach that has worked well for me over the years to arrive at a roadmap that is outcome-oriented, comprehensive, and primed for great execution.

Part 1 — What are we building?

I first start by looking at the roadmap as a collection of “whats”. These are larger “categories”, “themes”, or types of projects that will eventually form the roadmap. More often than not, each project that we take up falls under one of these categories. These are:

1. Technical Debt
2. Design Debt
3. New Features
4. Feature Enhancements
5. Product Growth

Technical Debt: Every software product, especially built by agile teams at breakneck speed, accrues technical debt overtime that needs to be tackled and duly paid frequently, before it goes out of control. As a PM, I always try to make sure I am close enough to my engineering team to understand what kind of engineering challenges they’re facing as we push releases out. These include, and are in no way limited to, outdated frameworks and technologies, spaghetti code, known bugs, performance issues, infrastructure and stability issues, and compliance requirements.

Design Debt: Similar to tech debt, design debt is an output of fast-paced releases and the ever-evolving world of software. Problems to solve here include inconsistent UX behaviour across similar components within a product, unexpected interactions and behaviour (a.k.a design bugs), outdated design languages (especially true for platforms such as Android and iOS that offer standard design guidelines), and inconsistencies across products offered on multiple platforms.

New Features: Probably the most exciting part of the roadmap, and one that some might (incorrectly) consider as the only job of a Product manager, this one is quite self-explanatory. It includes building new capabilities into the product that did not exist previously — a quick litmus test to distinguish this from a feature enhancement is to ask yourself — are you allowing users to do something they’ve never been able to do in your product before? If yes, then you are building a brand new feature alright. This category could also include spawning of new product lines and building new integrations.

Feature Enhancements: The most populous category by far — trust me, you will never run out of things to do here — this covers all improvements that you want to do on previously existing features. Now, it should be noted that there might be a significant overlap between this category and design debt as the latter tends to list enhancements from a UX perspective as well. However, I usually bucket projects under feature enhancements when an existing feature is made more powerful by building new capabilities on top of it, instead of just introducing better ways of using the same feature — the latter would be a design debt.

Product Growth: The most impactful part of a roadmap IMO, this is where you’re driving metrics by continuously measuring and experimenting. This category includes moving all KPIs and metrics within the product such as activation rates, conversion rates, adoption, engagement, and user retention. Now, it should be noted that this responsibility might not fully fall with the Product team and could possibly be shared with a separate Growth team, or more commonly, the Marketing team.

Now that we have our categories or “whats” defined, in the next post we will delve into how to populate these categories with the problem statements we want to solve. Stay tuned!