How to be Nostradamus … or … How to Construct a Product Roadmap in an Agile Environment

How to be Nostradamus … or … How to Construct a Product Roadmap in an Agile Environment

Here’s the ultimate contradiction for Product Managers.  Most of us want to work in an agile fashion, building in two or three week increments while responding to market feedback.

Yet we’re also being asked to steward a roadmap that might look out a year or two.  This is paradoxical.  These are two opposing religions!  How can I root for Liverpool and ManU?  How can I be an early bird and a night owl?  How can I enjoy and at the same time detest country music?

The truth is that the roadmap is a useful tool for many teams.  For product managers, the roadmap is a way to thoughtfully lay out a product vision or strategy.  For marketers, the roadmap is a tool to activate the market.  For salespeople, the roadmap is a tool to cover up for feature gaps in the product when closing an opportunity.  (That last one made you shudder a bit, didn’t it?)  It’s hard to find fault with any of the utilizations.  Each team is using this tool to accomplish the very thing that gets them paid.

Here’s the problem: Product managers are pulled in two directions.  On one hand, we live sprint to sprint, iterating on the product and responding to real-time customer feedback.  Yet, with a roadmap, we’re also being asked to predict the future.

I am going to do something sacrilegious to a PM: Try and make everyone happy at once.  How?  Reframe your roadmap to not be around features, but around problems.  Adjectives over nouns.  Problems are often easier to predict.  As an added bonus, honing in on problems helps us rationalize as product people.  For example, do I really want to invest in chatGPT right now?  What problem is it solving for the customer?

This approach does not lock in the roadmap for the next three years.  The world changes and you may select different problems to solve in the future.  However, it’s less of a commitment around features and provides more flexibility as you continue to learn from customers.

The other trick to employ in roadmap communication is defining bounds.  They work like this: “To solve Problem A, we will at least do [thing A] and at most [thing B].  The bounds don’t need to be part of the roadmap but should be maintained as responses if your roadmap audience asks for more detail around the problem solution.  For example, instead of integrating with a specific SaaS app, the roadmap will specify that we want to open up our product to other services in the ecosystem.  Someone might ask: What does that mean?  Well, at the very least we want to improve our API to be consumable by more external services.  At most, it could mean building direct integrations to apps like A,B,C.

The “problem-lens” is most attractive to customers because it conveys empathy and an outside-in approach to product strategy.  No longer are we focused on our product and its features, we’re focused on customer problems, challenges and goals.

(By the way, did you know I’m hosting a course on data analysis for PM’s? We’d love to have you! (And use promo code PILOT23 for 50% off of the course.)