How to Build Your Product Roadmap?
This is part 8 of a long-form series of setting up your Product Stack’s Project Management correctly.
You can read Part 7 about the process of planning your sprint and conducting your Scrum processes here.
In part 2, we discussed how Project Management tools are structured and how to visualize your entire Product Roadmap onto a ‘Plan’ which is a representation of the Issues to build and an estimate of their timeline in the two-dimensional space.
In part 6, we discussed how to track the progress of your deliverable Epics and how to break Epics down into individual tasks or Issues that are assigned to individual teams.
We, however, haven’t discussed the problem of stitching everything together to make a visual representation of your entire roadmap of products and their delivery timelines for your entire organization.
Project Types
We’ve already established the unit of constructing an organization-wide Raodamp is a Plan on a Project Management tool. Recapping our example we created the following Projects -
Initiative Projects
- EasyRide Demand
- EasyRide Supply
- EasyRide Operations
- EasyRide Marketing
Please note that the Initiative Type Projects are solely created for you to map your Business Objectives to the Initiatives that you devolve your objectives to. Notice that the names that we’ve given to our Initiative-type Projects are largely Business Function names that exist commonly across organizations. This isn’t an exhaustive but a suggestive list. Feel free to add more Projects in your business objective space such as ‘Network Planning’, ‘Customer Experience’, etc. depending on whatever is important in your organization to have your business objectives planned around. Please also note that the Initiative-type Projects can be continuously added as your organization or your planning process evolves.
Let’s take the example taken in part 1.
Initiative — Introduction of a Loyalty Program that gives a discount percentage on each cab booking on payment of an upfront fee per month. For this, we’d create the following Initiative-type Issue -
- EasyRide Consumer Loyalty Program
Please note that adding a version to your Initiative Issue Types might not add much value since you’d be undertaking one Initiative uniquely only once. The probability of starting up a second or third version of an initiative would be low since initiatives would be tied to business objectives.
Product Projects
- EasyRide Consumer
- EasyRide Agent
- EasyRide Driver
- EasyRide Admin Dashboard
Please note that the actual deliverable Features and Epics Issues will always be created with the Product-type Projects since these would be actual instances of Products across which you’d be building to support an Initiative. Each Feature created for a Product should be uniquely associated with a parent Issue Type — an Initiative belonging to an Initiative-type Project. This is how your Initiatives are first devolved uniquely to your Products in your Product stack.
Let’s take the example taken in part 1 and devolve the Initiative into 3 features -
Feature 1 — Loyalty Program Purchase Flow on the Direct-to-Consumer App and Website
Feature 2 — Loyalty Program Discount Percentage addition to checkout flow on the Direct-to-Consumer App and Website
Feature 3 — Loyalty Program Discount, Per Order Capping, and Number of Orders Capping Configuration Feature on the Admin Dashboard for Dynamically changing values
Hence, we’d have the following Feature-types Issues -
- EasyRide Consumer Loyalty Program Purchase — v1.00
- EasyRide Consumer Loyalty Program Application — v1.00
- EasyRide Admin Dashboard Loyalty Program — v1.00
Please note that as a best practice, you should version each of your features on the Issue name while creating an Issue on your Project Management tool. Versioning would help you for iterating and building the next version of an existing feature which would be used to serve the same initiative.
Deliverables
In order to next map out your deliverables from the above-mentioned Features, you’d roughly divide what you’d be able to deliver in the form of a unit of work such that it’d be usable end to end by a user. Please note that out of the three features mentioned above, you’d be able to release each feature separately to your users. You’d have the following three Epics -
Epic 1 — Loyalty Program Purchase Flow on the Direct-to-Consumer App and Website
Epic 2 — Loyalty Program Discount Percentage addition to checkout flow on the Direct-to-Consumer App and Website
Epic 3 — Loyalty Program Discount, Per Order Capping, and Number of Orders Capping Configuration Feature on the Admin Dashboard for Dynamically changing values
Hence, you’d theoretically be able to create three Epic Issue-types for the three features as follows -
- EasyRide Consumer Loyalty Program Purchase — v1.00
- EasyRide Consumer Loyalty Program Application — v1.00
- EasyRide Admin Dashboard Loyalty Program — v1.00
You could have the same name for Epics and Features or name them differently. At an Epic level, since you’d be deciding your deliverables, you should start coming up with a rough estimate of your delivery according to the effort involved.
The next step of the division of your Epics should get started with your process of building products in either Scrum or Kanban style as mentioned in this article. The next set of issues on your Project Management would be created after breaking down these requirements further with your Design and Engineering teams.
Roadmap
For constructing a Roadmap, you’d first have to create a Plan as mentioned in the document linked here.
Therefore your roadmap should look like the following -
The plan displayed above shows all the Issue Types discussed plotted together with their hierarchical relationship, timelines, current statuses, and expected start and end dates.
It’s up to you to choose the depth of the parent-child relationship hierarchy that you want to display in this roadmap. If you wish to not dive deeper than Epics, then you can choose only until Epics in the Filter that’s displayed at the top.
Let’s dive a little bit into the details of the roadmap constructed in the above diagram —
Hierarchy
We can clearly see the hierarchy of the Issue Types with each other and the parent-child relationship between the corresponding issue types. Thus, this roadmap becomes the single source of truth for the entire organization of the forthcoming Product Initiatives, which Business Objective is each Initiative targeting, and what Features will be built across each Product in the stack to achieve these Business Objectives in a single snapshot.
- This Issue Hierarchy would enable multiple stakeholder types to view this Roadmap according to their own needs.
- The Chief Product Officer or the Head of Product may only want a visual representation of the initiatives to be undertaken in a quarter or a year.
- The Group Product Managers/Lead Product Managers/Principal Product Managers might want to visualize the set of Features to be built by their teams.
- The Senior Product Managers/Product Managers might want to visualize the deliverables Epics that they’re in charge of.
- The Associate Product Managers might want to visualize the deliverable user stories that they’re managing
Dates
The diagram also reflects the start and end date of each Issue Type that you want to plot on the Plan. This gives a clear expectation of the committed dates to your teams across the organization. This should become the basis of planning your inter-organization Product features by accounting for the capacity across each team.
Most of your Product team would want to affix dates on each Feature and Epic to understand the effort estimation of each Issue.
Visual Timelines
The visual timelines are the long bars of time spans which when filled for any Issue Type provide a pictorial representation of the deliverable of each Issue Type across the entire organization. These timeline bars give the appearance of a Gantt chart to your Product Roadmap. The careful span of these bars should be plotted to give your organizational stakeholders a clear picture of the upcoming and future deliverables.
Most of your top management would want a Gantt chart representation of your entire plan in one single place and how this is evolving continuously.
Issue Status
In part 4, we discussed all the Issue Types and their corresponding statuses that would be needed to uniquely report the current progress on each type. These Issue Types can be reflected in the visual presentation of your roadmap to give your stakeholders a clear current snapshot of your Product Roadmap.
Most of your business stakeholders require the status of their current expected deliverables and the expected timeline of the same.
Please note that the process of estimating Issues in your Roadmap and arriving at timelines for your deliverables is the opposite of the process of breaking down your requirements.
While you go top-down for deciding what would feature on your roadmap, you go bottom-up for estimating the timeline of delivery since the lower the granularity, the more accurate are your estimations.
Summary
We’ve now concluded our journey through this series of articles for understanding the Project Management of Products for a modern-day organization.
You should conduct this activity of road mapping every month or every quarter to fix the roadmap for your next month or next quarter. Every month or quarter, you can reasonably be assured of what you want to prioritize next.
It’s important to clearly understand the roles and responsibilities of each and every person on your team, their tasks to be performed, how their tasks ladder up to serve a Product objective, and how this Product objective ladders up to serve a business objective for an organization.
It’s also critical to adopt your own style of Product building as a process and tweak the process of prioritization, estimation, routine meetings, the process of building, and reporting progress.
Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn
