Product Management

It’s time to ditch roadmaps. More often than not, roadmap presentations leave me unsatisfied. Perhaps it’s the pressure to “do product management right,” or the weight of the roadmap’s established place in the product world as the artifact — you can’t NOT have a roadmap and be seen as credible. Whatever the reason, roadmaps often seem to be a trick and pony show — look at what we are doing soon 🤩, somewhatsoon 🎉, and later! 🏆 They are often inaccurate, always changing, and fail to produce consensus.

Perhaps I have been a bit harsh here— there is indeed value in product roadmaps (please do not misinterpret me here), however, we too often use roadmaps when we should not. It’s in these scenarios that we need to rethink the roadmap and replace it with something better. Let’s break this down into two categories:

When are Roadmaps Valuable?

Roadmaps are valuable when:

• Executives, clients, and stakeholders need a window into development progress and what’s coming next
• You want to promote excitement about new offerings or components
• Clients and customers need a place to see that their needs are being heard

Roadmaps are less effective when:

• You’re trying to build clear consensus within a development team
• You’re trying to promote or craft a product vision and create momentum
• You’re trying to decide what not to do
• You’re defining the problem space for your product

Here’s one scenario that illustrates the point. In the past, I worked with a development team to build a product. The product evolved and was repositioned as a larger contributor towards new company goals. Naturally, the team was reallocated, put under a new manager, and given a new set of “to-dos.” Despite being a bit bitter about losing control of the product, the team still reached out to me to help. One pervasive sentiment stood out — “We feel lost! We need to see the product roadmap!” Interestingly, roadmap presentations were a regular and consistent practice within the team — the team DID have access to the roadmap in an intentional and curated way. What was prompting the team to ask for it again and again? Why were they coming back to me as opposed to their new leaders?

In another, more awkward scenario, I recall being a contributor in this type of situation myself — the entire product team shouted out with desperation, “…but what is our roadmap? What are we trying to build?” I realize now that this was probably the wrong question and totally unfair to an executive caught off guard trying to answer a misguided plea — I could sense the growing frustration from a VP who felt his product team was insatiable for more despite clear and wise answers to the proposed questions. I wish now that I approached the scenario differently. Landscapes have helped me reframe what questions to ask.

Product Landscapes

In these particular circumstances (and the need is always unique to the team and problem set) we can parse the underlying request from the team as “We feel lost — we need to know where we are going!” Roadmaps, in contrast, are valuable when the goal is to distill and generalize what’s coming. It’s a way of cutting out a little picture of a destination and pasting it on an tri-fold poster (who remembers these?). An internal development team (including product, UX, QA, and developers), needs much more. “Where we are going” can be reworded a different way — what’s the vision? What is our course? What are we trying to avoid? The need here is for what I call a product landscape.

A product landscape is a “map” or mental model of where the product is going and what it could be. It focuses on the less tangible concept of product identity and mission.

Here are a few key elements of what make up a product landscape:

• Product landscapes inherently focus on exposing the logical boundaries of a product space — they are not focused on exposing a timeline
• Product landscapes intentionally include complete unknowns — unlike roadmaps which work very hard to reduce exposing unknowns
• Product landscapes draw relationships between components — roadmaps draw relationships between features via releases and when groups of work will be delivered
• Product landscapes present a complete picture or “master plan” for where the product is going and what could exist. Roadmaps give you just a taste of that future reality

Others have laid the groundwork for thinking of products in similar but distinct ways:

• Sjoerd Nijland outlines the need for product boundaries and a well laid product foundation with a “product domain.” This is still distinct from a landscape in as much as it focuses on things like risks, stakeholders, competitors, users, etc. Landscapes, instead, focus on a master plan for components.
• “Story Mapping” is a common design practice that works to break down specific features into tasks or actions. It uses groups of boxes to help display the full narrative and lifecycle of how a specific product or component may be broken down and executed. This focuses more on story content and writing vs. defining the larger space that an entire product should cover.
• There are countless other examples of removing the timeline aspect from roadmaps like ProPad’s article here. This is less related to a landscape than it is to recognizing the need to have some place to work without deadlines being a driver

Here’s a theoretical product landscape for a theoretical app meant to help residents of a city find the best parking spot. I use whimsical as my primary thinking and drawing tool — highly recommend). This landscape is intentionally small and limited to help introduce the concept.

When constructing a product map, I recommend a few things:

• Use colors with large boxes to group components or component sets. In this case, “City Management” and “User Lifecycle” are two distinct logical groupings of the product experience geared for different user types
• Give features a parent component. Do not conflate components and features. In this case, each existing component is represented by the dark solid boxes. The features that are lighter in color help make up the parent component. (Components are a larger block of work that help meet a specific business case. Features are the actual technical tools designed to help meet that use case)
• Use hierarchies to represent nested or logically related components. In the example, one must have a city before being able to add its parking locations and therefore track parking availability at each of those locations
• Include what does not yet exist but could. In my theoretical app, I’m betting that electrification of the car industry will present new opportunities to integrate with internet-connected charging stations. I’ve “bet” that we need to add these components by using a box with a dotted line and no fill.

I encourage you to go back to the key elements of the product landscape I outlined above the diagram. Take another look and digest how these elements ring true given the example.

Landscapes+

You can one-up your product landscapes by:

• Including a product brief, vision statement, and marketing material directly alongside your map. (Whimsical Docs are great for this)
• Comment on certain features or components to include context or additional detail
• Extract parts of your landscape when constructing a roadmap and present it as a way to set context. Here’s the product landscape — now here’s how we get there.
• Creating multiple product landscapes for different product offerings within the same product

Once you have a landscape, you can use it to build consensus within a product team, getting product people themselves to speak the same language and work with the same mental models. Without a landscape, each PM may have a different version of the master plan or make assumptions about logical bounds or the relationships between components.

Product landscapes won’t always be the right choice for you and your team in every scenario. However, when used well, they can do a lot more for an internal team to promote vision and drive a feeling of “knowing where we are going” than a roadmap can. They are detailed enough to go beyond the generalities of a roadmap but still easy to understand and change quickly. Use them to bolster your toolset as a product manager and drive products forward.