A Product Manager(PM)'s roles and responsibilities vary from company to company, depending upon the size of the organization and the industry it's functioning in. However, the common thing for all PMs is to come up with a roadmap.
So, what is a RoadMap?
A roadmap is, typically, an artifact that a PM comes up with after actually figuring out the strategy for their area, making the decisions around what they would be prioritizing and how to use the engineering team. Basically, a living strategic artifact to let the internal stakeholders know where the product is headed.
Keep in mind the end of your roadmap in mind, though, since working backwards from it is the way to help you in sharpening your thinking part and eventually, figuring out the right thing to do for your area.
The caveat here is that the roadmap should be built in a useful manner, providing clarity to the important stakeholders such as the engineering team, marketing & sales team and so on.
Before we start discussing the roadmaps, it's important to know about some principles, i.e. shortcuts to keep in the back of your pocket, for what roadmaps achieve regardless of how you make it.
What you achieve by creating a product roadmap?
The first is to draw a clear line to the customer, articulating themes that tie back to the market of customers the focus is on to account for the customer's perspective. The other thing about a great product roadmap is achieving the set time delivery expectations. The members of the audience should be able to identify clearly what's being tested versus the full launch kind of work. Next, the key milestone has to be clear. It could be hitting a certain metric like certain monetization rate. Finally, it's all about completing the loop. Great roadmaps tie together the delivery launch pieces, developments in the ecosystem. Always wait for the feedback and the other risk factors before finalizing the roadmap.
One thing to always keep in mind is never to over-commit. And, it's much easier than one can think. Usually, once a feature is launched then, something happens and some time is spent after which, the feedback is received from the market. It's then incorporated into the roadmap to work upon when the product environment is changed (Business environment is dynamic in nature, remember?). Either it's from the market's side or the competitor does something different. Again, that's incorporated and the cycle continues. You're always learning from the environment which keeps on changing your roadmap.
Don't forget, the information isn't going to come to you. It's not that straightforward. This is to say, it takes time. Taking enough time to learn and adapt to it is important. So, the roadmap is to be built for all that uncertainty. Although, not by over specifying what the roadmap is going to contain in the terms of launches. This is where a PM has to exercise judgement making things difficult for him/her. It's like an art, what to be shared and what not in the roadmap.
Let's dive into some popular templates to get a better understanding of roadmaps
Time-oriented Roadmap:
This one is to go for if you've a small product area's responsibility because it allows you to go into depth. Honestly, this is exactly what cross-functional teams expect so, it's the roadmap you're responsible for. It does two things; sequencing your releases based on time and clearing out what the critical dependencies are.
Release-based Roadmap:
It's the most simple roadmap one can look at visually but, the essential work to do here is to decide what NOT to show. In contrast to the the time-oriented roadmap, this one paints a much higher level picture. It's actually very Marketing and Sales friendly since there aren't that much of details. It doesn't commit any team to specific features and hence, can be easily repurposed to share externally.
Thematic/Theme-based Roadmap:
A really great structure for complex or large scope roadmaps. The left-hand side features the themes while on top is the timeline. It's a great way to convey how you're deciding to build features and what you're going to build referencing to the themes. The other things great about this structure is its upwards and downwards communication and the management of expectations.
Now, these were just some templates that are widely used. One can always make a roadmap as per his/her convenience and liking and what works out for them. There are various software products available to help you out with the same as well.
To conclude, it's all about getting the right information out for the concerned stakeholders and teams to function and deliver based on what a PM expects. However, how to make it compelling is what I've tried to convey here in the best possible manner.
