Product Management In 5 minutes (Part 2)

“Engineers— Why are we doing this now?
Me — (states reason)
Stakeholders — What are we doing next?
Me — (states the next phase)
Marketers — What’s the actual plan?
Me — (rolls eyes and stare’s at them), You know what, kindly go through the Product roadmap I created so we’d be on the same track…(walks away to avoid another question)”

As PMs, you are assumed to hold an ability to improvise and these are all questions that, as a product manager, you might hear from anyone in your organization, from stakeholders to engineering and sales to customer success and marketing. And yes, it can be frustrating. Having given justice as regards product management as a concept and differentiating product and project management in the previous part, in this part we would go deeper into the product management & development process where we would look into Product Management Roadmap & Types.

Press enter or click to view image in full sizeProduct Management Roadmap & Types Image representation by Yasir Gaji

But, why do we need the product management roadmap? We need it to ensure the product team is on the right track from the moment the product was conceived, planned, developed, iterated, launched, and kept in a steady state.

So, what is a product management roadmap? The product management roadmap is a “Living document”, a “Visual summary”, a “Plan of action” of a product’s direction to facilitate communication(with customers, stakeholders, prospects, clients, and partners) and how the product or solution would evolve over time. The product management roadmap would articulate your product strategy so everyone, including different audiences with unique needs, understands it.

Building The Roadmap

You need to take into account market trajectories, value propositions, and engineering constraints when building a roadmap, a basic roadmap will usually include feature and product releases, but it is beyond that, and most roadmaps are beyond that. here are some items that a product roadmap should include. A timeline, task description, feature and strategic releases, strategic milestones, data-data-data, business or team initiatives, epics, goals, and user stories.

For a product manager just beginning to put together a roadmap for a product, there are fundamental questions to ask first, such as, “What should the roadmap include, focus on, and look like?” and “What is this roadmap supposed to do?”

Principles of creating a product roadmap.

As PMs, we are expected to hone the ability to improvise but in tech, things move so fast that unexpected corners could be born from situations. As product managers, we should be prepared for such corners which bring about the first principle which is to Hold the ability to improvise but always anticipate mistakes this way you would be able to assess vulnerabilities and understand the product better.

The next principle is Knowing what not to include as product managers we are required to have good communication channels that way saying no would not cause a problem within and between the product team. Once a general vision is in place the product team has to breed consensus.

A rule of thumb suggests that you start with the big ones, and then think of the interstitial gaps that can solve more problems and suggest ideas at the same time. This implies that as product managers we should Understand the art of feature categorization which is the third principle of creating a product management roadmap.

Types of Roadmaps

01.
The Release plan roadmap can be considered as the execution-level plan of how you’ll deliver the work that you’ve decided to do and the timeframe when you’ll complete that work. A release plan communicates a high-level overview of upcoming product releases to stakeholders, product teams, and even customers. It’s ideal for planning milestones not time-bound, but with a fixed scope or new versions of your product on a regular release schedule (a mobile app for example). It lets other teams know features are coming soon without committing your team to a specific launch date.

02.
The Sprint plan roadmap is a granular delivery-focused and, of course, useful for sprint planning. Products teams use sprint plans to align their development teams with upcoming work so they’re always up-to-date and in sync. You can plan your delivery over multiple sprints and show each feature’s effort and owners to monitor your team’s workload.

03.
The N²L Plan roadmap communicates your priorities over broad time frames with an emphasis on the now-next-later-term, in three slots. Features in the ‘now’ slot have more detail as you work on them, while features in the “later” bucket will be more high-level and reflect your long-term strategy, you probably guessed what would be in the ‘next’ slot. They are perfect for product teams operating in fast-changing environments where release dates may change and allow you to communicate comprehensive plans to customers without committing to specific deadlines rigorously.

04.
The Kanban plan roadmap is another delivery-focused roadmap for development teams. It helps product teams clearly group initiatives into buckets of backlogs(what you’re planning, what is in progress, and what you’ve completed). kanban plan allows product teams to communicate their near-term plans without committing to exact dates. You can showcase when you’re working on specific features and as well remind them what they’re building towards.

05.
The Features-Timeline Plan is an output-driven roadmap that allows you to set the time frame for an individual feature. Planning features and tracking progress with a timeline roadmap is ideal if you want to get a 1000-foot view of how work is progressing toward a deadline or time-bound milestone. You can track feature progress against specific deadlines and milestones and align internally with development teams on concrete dates. You can also allocate resources when and where they’re needed.

06.
The Objective-Timeline Plan roadmap is an outcome, not an output-driven roadmap. This roadmap provides broad organization alignment on product direction. It’s easy for anyone to understand when you’ll work towards each of your business goals and where that sits relative to your most significant milestones. It’s for larger organizations and those working in more complex environments, there comes a time when senior executives and stakeholders want a more zoomed-out approach about the product.

07.
The Release-Timeline Plan roadmap allows you to plan and communicate when you’ll work on releases in the near future with clear timeframes to cross-functional teams, like sales and customer success. Stakeholders can see what’s slated for the next app version, monthly bug fix, quarterly release e.t.c. With product management software, like Productboard, larger product organizations with multiple teams releasing features on different cadences can create multiple release groups to organize these and keep cross-functional teams in the know.

08.
The Lean Plan roadmap is a strategic tool that provides alignment, focus, and predictability, but it is not a Release Plan or a Product Backlog. It consists of issues, needs, benefits, or problems to solve for the customers, clients, and/or company, always linked to the product objectives.

09.
The Portfolio Plan roadmap is a visualization of the strategy and timeline for all product efforts across an entire group. It showcases multiple product plans on a single roadmap to help executives and product managers understand how each product relates to the overall goals and initiatives.

10.
The Agile Plan roadmap provides crucial context for the product team’s everyday work and should be responsive to shifts in the competitive landscape. Multiple agile teams may share a single product roadmap.

Conclusion

For our success as product managers product roadmaps are extremely crucial, note a product roadmap is not a one-size-fits-all strategic plan but all roadmaps have some basic essential characteristics in common. They should be easy to update and share, high-level, visual, and easy to present to any audience. I expect questions for clarification. In the next part, we would learn about Ideas and User needs.