How To Build An Achievable Product Roadmap?
Talk to any of the product managers, and one of the main problems they will share how difficult it is to create an achievable product roadmap. I have mentioned “achievable” in the title because, most of the time, the product team comes up with a roadmap only to realize that it’s not achievable.
This could happen for multiple reasons. Maybe the estimates were not accurate. Perhaps the unknowns were not taken into consideration. Or maybe a different project became a priority. And when this happens, it demotivates the product manager and the entire tech team.
In this article, We will tackle what goes wrong with today’s product roadmaps, and we will talk about how a fast-paced mid-size startup found exciting ways to create a roadmap that’s indeed achievable.
Product Roadmapping Basics
What Is A Product Roadmap?
A product roadmap incorporates all the details necessary to finish a project. This roadmap could be yearly, half-yearly, or quarterly. This is then divided into monthly and, in some cases, even weekly. The idea is to break it into smaller achievable parts so that the engineering team has tangible outputs. There are some other reasons as well why product teams use roadmap. Some of the reasons are:
- It acts as a source of truth for all the teams involved.
- It helps to check whether or not the team is moving in the right direction and at the right pace
- It helps to understand what exactly all the involved teams need to do to achieve the main goal
- It helps to understand the dependencies of other teams
Without a product roadmap that aligns all stakeholders, it’s almost impossible to build a victorious product.
Who Are The Stakeholders of A Product Roadmap?
The product roadmap is an artifact used by the entire company. Ultimately, anyone impacted by the product is a stakeholder of the product roadmap. The top stakeholders of the product roadmap are:
- Product manager — The principal owner of the product roadmap is the one who owns the product development process. And this responsibility falls in the bucket of a product manager.
- Engineering and design — Any team directly or indirectly dependent in one way or the other with the product is also actively invested in a product roadmap. This usually comprises engineering and design, who will be helping execute the items in the roadmap.
- Higher management/executives — They are also interested in the roadmap since they want to know when the projects will be completed.
- Sales/marketing/customer service — Other than that, several other teams are not only interested in the product roadmap but play an active role in shaping the roadmap and the initiatives included in it. They are namely sales, marketing, and customer service teams.
- Internal/external users — And in cases where users of the product are internal (or even external), they also are one of the stakeholders of a product roadmap.
What Is Wrong With Today’s Product Roadmaps?
Product roadmapping starts with the product manager, who understands the users’ problems, talks to the engineering teams, gets estimations, and creates a roadmap. Post-creation of this document, it will be shared with all the relevant stakeholders. That’s the traditional way of creating a roadmap. But what if I tell you this way does not work anymore in 2022?
I have talked to many product managers, and there were quite a few common issues that most of them narrated. They are shown in the image below.
- Treating roadmap as a finished document — Most companies think that once a roadmap is created, it’s a finished document and should never be changed. They treat it as a static document. They devote a month to building a roadmap and then lock it.
- Not letting dependent teams participate early — A Product manager creates the roadmap in a silo, and the dependent teams share their concerns about the roadmap later during the creation process.
- Inaccurate estimations — Teams cannot correctly estimate the work, thereby setting up unrealistic expectations.
- Unable to divide the roadmap into executable parts — The product manager not being able to divide the roadmap into smaller executable parts, making it challenging to map the high-level roadmap to low-level requirements.
How To Come Up With An Achievable Product Roadmap?
I recently chatted with a product manager in a mid-size startup and was pleasantly surprised to know how she and her team are solving these challenges. It was interesting to see that she has been successful in crafting roadmaps that were achievable most of the time. She shared some fascinating insights. I noted them down. Let’s dive into what she and her team are doing right.
Iterative roadmapping
Create a roadmap iteratively. Include all the relevant stakeholders (users, designers, engineers, marketing, sales, higher management) right from Day 0. Take their feedback early on and keep them in the loop throughout the entire process. This way, as a product manager, you will be able to address their concerns right from the start. A good practice is to create a recurring bi-weekly meeting with all the stakeholders for a month or until the roadmap is finalized. This way, you can improve the roadmap continuously while keeping them aligned. Also, even though the roadmap is finalized, understand that there could be unknowns in today’s ever-changing product development process because a roadmap might need to be changed. Always consider a roadmap as a strategic forecast rather than a mandate.
Backward approach
Via this approach, figure out what you want to achieve in 1 year that’s aligned with the company’s strategy and vision. Divide this 1-year plan into two 6-month roadmaps and then create quarterly roadmaps. Divide the quarterly roadmaps into a sprint-by-sprint plan. This will help you to connect a higher version of a 1-year roadmap with a smaller version of the sprint-by-sprint plan. This is one of the ways to understand how achievable your roadmap is.
Estimate the knowns
One problem that appears while creating a roadmap is properly estimating the work. This plays a vital role in determining whether a roadmap is achievable or not. It’s tough to estimate exactly how much time it will take to finish the roadmap. But one of the ways that the product manager of the mid-size startup shared was to divide the roadmap into more minor themes. Then let the engineering team estimate each of them with t-shirt sizes (S, M, L, XL). This will help you to guestimate the roadmap. T-shirt sizes aren’t perfect estimations, but they sure are close to excellent.
Identify team capacities
Another problem related to incorrect estimation of a roadmap is not knowing the available team capacity. By capacity, she meant how many engineers and designers needed to finish the roadmap were available for the specified time. In most cases, this small information isn’t considered, impacting the roadmap. To overcome this problem, her team created a sheet at the start of the year and shared it with all the team members involved in the product development process. She asked them to enter their probable holiday plans. While calculating the capacities, she considered these holidays of the team members as well as public holidays. This gave a pretty good understanding of the overall available capacity for the roadmap.
Estimate the unknowns
If you have worked in product development, you know it’s complicated to find all the use cases in one go. Even if you know the product inside out, a new use case might pop up. And this happens 9/10 times. How do you tackle such unknown use cases?
Unfortunately, no one can predict these use cases, so the best way is to keep a buffer. If the timeline you got from the engineering team is 3 months, always keep a month of buffer for the unknown. Of course, this depends on the project’s complexity and how comfortable the tech teams are with their predictions of estimation and understanding of the projects. But keeping a buffer will help the roadmaps to be more achievable.
Define sprint goals
“Once the roadmap is divided into a sprint-by-sprint plan, let every sprint have a tangible sprint goal,” she said. Give demos to the users at the end of every sprint (if they are internal users). “In the end, you will be able to visualize how all these tangible goals add up to the roadmap,” she added. This clearly happened with her team when they started creating tangible sprint goals.
These measures helped the company deliver a roadmap that was achieved. An achievable roadmap increases the trust and confidence in the product team. The company was able to deliver products on time, thereby having a positive impact on the users. Also, the fact that all the stakeholders were involved right from Day 0 helped the alignment process and removed the blockers.
The software world in 2022 is evolving faster than ever. There are a lot of moving parts and multiple variables. And this affects the product roadmap in various ways. With growing problems, the world needs evolving solutions. However, the above-listed points look pretty strong, and considering the fact that they have already made a company’s life easier speaks volumes about the approach.
What do you think about these points? Have you faced issues during or after the product roadmap is finalized? What were these issues, and how did you overcome them? Feel free to comment below.
