Roadmapping a Quarter — Part 2

A Product Manager’s guide on getting it right

In the previous post of this 2-part series, we started the roadmapping exercise by looking at the larger categories, or “what” we want to build. In this post, we delve into the “whys”. These are essentially problem statements that we want to solve — or simply put, the answer to why something needs to be built. These usually come from various sources within the organization — most commonly, the various functions of the company.

This is an important exercise, as it provides an opportunity to Product teams to align their goals with those of other functions, identify problem statements that will drive maximum impact, and amplify the outcome of their efforts.

Here are some questions to ask across functions to uncover some of these problem statements:

Engineering

“How is the stability of the product (e.g. crash reports, API failures)?”

“How many production issues have we had in the past quarter, and what’s a trending root cause?”

“What are the biggest challenges in making releases quickly and of high quality?”

Marketing

“Are there any acquisition activities planned that might increase the number of users?”

In general, it’s also best to uncover any dependencies that marketing initiatives might have on the product & engineering teams for their projects. Is there anything that needs to be built into the product to, say, qualify leads better?

Sales

“Any big deals in the pipeline that might have a specific requirement not yet supported by the product?”

“What are the top 3 features that we are lacking that lead to most lost deals?”

Customer Success & Support

“What are the most frequent feature requests from customers?”

“What’s bringing in the most support escalations to the engineering team?”

“What are the top complaints from users?”

Product and Company Strategy

Beyond each function, the overall company (and product) strategy for the year forms a big source of problem statements. Are there any big integrations or partnerships that we need to enable? Are there any industry compliances that we need to adhere to to stay competitive in our market (e.g. GDPR)? Is there anything we need to build to keep existing partners happy?

Once the problem statements or the “whys” are identified, the “hows” take shape — and these are the specific projects, features, and activities that will solve the problem statement and will eventually be the more tangible output of the team’s effort at the end of the quarter.

I’d also like to point out a few other things at this point — some probably deserve blog posts of their own, so I won’t go into too much detail. Keep an eye out for future posts!

Start early — give yourself at least 2 weeks at the end of the current quarter to plan for the next one. This is a non-trivial exercise and requires a lot of mind space.

Keep an eye on the company’s goals — For most product-led companies, a lot of the growth is driven by the product but not necessarily the product team. If, however, you are responsible for driving a lot of the company’s growth, make sure you have the company’s year-end goals in mind and bring that into your product’s roadmap as well (probably via the “Growth” category described in the previous post).

Proportions of focus — While we have 6 categories defined in part 1, and you might have even more or less, keep in mind that rarely would you dedicate equal attention and resources to all 6 categories in a quarter. It’s important to decide the proportion of focus that is required — is the product too unstable? Engineering might need most of the resources in the quarter. Are we being bullish and expanding market share? Product might need to support sales and marketing heavily.

That’s it! After days of conversations, discussions and debates, I end up with a long-form of the quarter’s roadmap. Why long-form? Well we still haven’t done project estimations yet have we! More on that in a future blog post.