What are Product Roadmaps?

Part 1 – Successful Roadmaps Series

Q: Why did the chicken cross the product roadmap? A: To get to the other launch date!

Product roadmaps are essential for any business and the success of a product launch. However, it can be easy to forget how important they are in the face of other tasks and problems.

Strategic and Vision Focused

A roadmap displays your strategic plan in a visual way and lays out the path your team will follow to get to the finish line. Let’s pretend you are in a spaceship. You are currently 60,000-feet above the ground. What would you see? Likely outlines of continents, oceans, and large land masses. If it’s cloudy, you will see even less. At this high level you are not going to see people walking around at ground level. At this high altitude you can see the horizon and the bigger picture which gives you a better advantage point than being on the ground level. Throughout history the higher viewpoint was linked to power and privileged, but in today’s world that viewpoint is readily available to everyone. Get the high-level viewpoint to understand how things are integrating together to form a better picture of the entire landscape. It can take a little work opening those doors, but once opened the view will give you incredible insight.

You’re at the 60,000-foot level looking down so you’re not going to be able to see many of the details you would find at a task level. You will need to agree upon the vision for your product, service, project, or release. What does the result look or feel like? What problems are you trying to resolve? Build the high-level capabilities that you will deconstruct later into features and functions.

High Level Prioritization

Once the vision and high-level capabilities are established, it’s time to start figuring out what order those capabilities are going to be delivered. The organization will need to prioritize the capabilities to define the order in which they will be developed. Typically, foundational things like servers, databases, or hardware are first on the priority list as they will be the base camp or starting point for capability development. Categorize the capabilities into groups: Now, Next, and Later. If those categories don’t make sense, develop new categories that are more meaningful for your organization.

Capabilities - Not Solutions

Capabilities are a combination of tools, process, techniques, technology and resources to achieve a specific purpose that align with a vision as part of a product or service.

Capabilities are a better way for showing progress to the overall vision when compared to solutions. If you’re putting in a new CRM system, you’ll need to create interfaces, build architecture and platforms for development and production, and many other technology-based tasks. These technology tasks don’t translate well into something the organization or business can understand. The business is trying to figure out which parts to the product or service other companies are the most interested in for marketing analysis. The business won’t find it meaningful to see things like integrations or API calls because they don’t speak that language. When creating the list of capabilities, it is best to keep them in straight forward easy to understand language that directly relates to business functions.

Roadmaps appear to be very simple visual descriptions of the path the team will take to fulfill the vision. When you watch a professional juggler toss around 3 bowling pins in the air effortlessly, you get the impression it is easy to juggle. The beauty of the juggler's performance is making something companies and difficult look easy and entertaining. Show your roadmaps a little love and give them some time for development and refinement. If you make it look easy, it will be easier for your team to follow it.

How to Create a Roadmap

There are many approaches to creating a roadmap. Here’s a simplified approach:

(1) Create the vision. We’ll talk about creating a vision statement and value proposition in future articles in this series.

(2) Deconstruct the vsion into capabilities. Deconstruct the vision into smaller capabilities that are needed for the product or service.

(3) Create business objectives for each capability. Business objectives are the measurable goals that are aligned with each capability. These measurements help determine with the capability is working up to our quality standards from an operational perspective. These goals are also used to indicate a problem might exist and we need to focus on that capability. We’ll talk about business objectives in future articles in this series.

(4) Prioritize the capabilities. Determine which capabilities are need most urgently for development. Keep in mind the logical flow of a roadmap. Your can’t build a house without a foundation so excavating the land, pouring the concrete, and curing the concrete for the foundation is the highest priority. We’ll talk about prioritization in future articles in this series.

(5) Group capabilities into releases. You’ll need to perform high level estimating like t-shirt sizes (S, M, L, XL) for each capability. With input from your team, try to group capabilities into releases that make logical sense. If you are putting in a new CRM system, you’ll need to research solutions, prototype potential vendors, and choose a solution in one release before moving on to acquisition and installation of hardware and software for the new CRM solution. Not all high prioritized capabilities may fit neatly together in one release. It might be beneficial to consider other independent capabilities as part of the release.

Release don’t have to be Q1, Q2, etc. Release can use the Now, Next, and Future prioritization model. We’ll discuss this model in future articles in this series.

(6) Create the roadmap. The roadmap is typically a visual representation of the work that has been completed up to this point. There are many different ways in which a roadmap can be visualized. We’ll discuss this model in future articles in this series.

(7) Deconstruct the roadmap into work. The roadmap can now be deconstructed even further into user stories, cards, or tasks on a project plan.