Visualize product roadmap windows#

Epics extend through multiple sprints, typically lasting between three and four months. EpicsĪn epic is a group of related stories-these stories might be interdependent or just linked by a unifying objective. As the smallest unit within a product roadmap, stories are the building blocks for the entire diagram-and because they focus on user functionality, the entire roadmap is built with the end user in mind.

Stories help keep development user-focused. The development team assigned to a story typically completes the task in a short sprint. A user story represents a single feature that will exist in the final product. Stories are the smallest unit used in product roadmapping. There are four standard units found in a product roadmap: stories, epics, initiatives, and themes. To achieve this, tasks are broken down into units of varying size and complexity. The goal of product roadmapping is to break a long project-often at least a year-into smaller, more manageable deliverables. (Tasks to be completed in the first quarter would be placed in the first column, etc.) Features and tasks are placed in these rows and positioned from left to right according to their respective time frames.

Each row represents a different team associated with the project.

Visualize product roadmap windows#

Across the top, a product roadmap is broken into windows of time (months or quarters, for example). Product roadmaps are divided into vertical and horizontal swimlanes. With that background information out of the way, let’s turn to the next natural question: What do product roadmaps actually look like? What aspects of the project (features, marketing collateral and campaigns, etc.) need to be developed?.A product roadmap-circulated across teams-should answer three questions: Project managers build product roadmaps to facilitate communication and cooperation. Here’s how product roadmaps can help things go right. So, there’s a lot that can go wrong-you’ve probably gotten that much. Your cows are out of the corral and running amok. In turn, your developers might hit unexpected delays and forget to communicate them to other stakeholders. Sales wants to sell the product and might make promises engineering can’t keep up with. They’re all pulling in different directions. Getting them to work together can feel a bit like wrangling cattle. Developing and launching a product takes the cooperation of engineering, marketing and sales teams. Project managers use product roadmaps to visualize the development of a product or service over time.Īt their core, product roadmaps are a communication tool. And, like most maps, it lays out a route between point A and point B-in this case, the beginning and end of a project’s life cycle. Let’s start with the obvious: A product roadmap, as the name suggests, is a map. So how can you maintain a project’s momentum and avoid getting caught in the weeds? You need something to get you from point A (inception) to point B (product launch). Miscommunication, delays, and other snags are practically a given. (There’s a lot that can go right, too, especially when you use a product roadmap! But more on that later.) On paper, sales, development, and marketing are all on the same side, but it often doesn’t feel that way in practice. From inception to development, there’s a lot that can go wrong in a project’s life cycle.