Making of a Bi-Directional, Prioritized Roadmap
14 April, 2021
We had a 3+ years product roadmap for our application and platform product lines. Every quarter, twenty PMs, Dev and QA leads, among others, would have two weeks of meetings -- due to time zone differences -- to discuss this very detailed roadmap. In these meetings, we would go through the roadmap rather meticulously, involving everyone in every little detail of it. Most people felt overwhelmed by excessive details, and resented having to sit through these long meetings. I also hated having to be on daily calls at 5 am!
The way the roadmap was developed didn’t allow us to see the forest for the trees. Immersed in details, we were missing high-level, important things. By being bottom-up driven, we lacked clarity of the strategic impact of each item on business value, and spent more time figuring out what would fit, instead of answering the why.
From my experience creating roadmaps in the past, I knew there was a better way. I decided to drive the change in how we approached the roadmap. To start with, I had the application team (led by me), the platform and technology team, make their lists of priorities. The lists should include whatever each team thought to be the most important for the next two to three quarters, and should capture an explanation of why that feature or module is critical to the business, and any customer or sales commitments. The product leaders should refine and iterate through this list with their own teams, until they have a list that they are willing to advocate for with the other product leaders, and eventually other senior execs and the CEO.
Following on that, all product leaders met for an offsite to discuss these priorities. The CPO launched the two day long meeting by sharing the strategic company-wide initiatives from the CEO. In this particular case, those goals were: be visionaries in Artificial Intelligence (AI) and obtain referenceability around certain industries. Other strategic initiatives came from us, the product leaders, including honing our competitive strength in certain areas, handling difficult implementation challenges, etc. This could be, of course, different for different companies, but the above examples should illustrate how broad strategic initiatives may be.
Each of these strategic initiatives was then weighted percentage-wise. Each product leader then presented their list, and we discussed and argued each capability until we came to an agreement on whether or not the feature would be included in the roadmap evaluation process.
Once this was done we consolidated the list with a feature in each row and the strategic initiatives in the columns. We then rated each feature high (3), medium (2), or low (1) against each strategic initiative. We calculated the total weighted value of each capability, circled the top three or four with the highest ranking, and did a gut feel check to confirm these were the right top features.
We, the product leaders presented the 3 or 4 strategic product priorities to the rest of the team, explaining why we chose them. We gave each team two weeks to come up with the scope for each of these priorities and work with Development to estimate at a high level. We then committed to deliver 2, 3 or 4 of the top priorities based on what could fit in the quarter. Some teams had remaining capacity, so the product manager worked with development to propose the other items that would be included in the upcoming quarter. The remaining top priority items were placed in the subsequent next 2 quarters, based on their ranking and product teams high-level estimates of what was feasible.
Finally, we circulated our 3 quarter roadmap to stakeholders, secured their buy-in, went to executives, finalized it, and committed.
- If a team cannot articulate two to three high-level themes, then the roadmap is too detailed. Everyone should know what those are and why they would make a business impact.
- Prioritization works best when it is bottom-up and top-down at the same time. The bi-directional approach ensures that everyone’s voice is being heard but also that all effort is aligned with strategic goals.
- No matter how well designed your roadmap is, include all stakeholders and secure executive buy-in before committing to it.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Albert Lie, former Founding Engineer and Tech Lead at Xendit, didn’t know what it takes to become an early engineering hire and not a lot of people around him experienced this unknown and arcane path. He had to learn it the hard way from the pitfalls he encountered along the way and he has been creating numerous frameworks to measure his growth and keep burgeoning in this role since then. He codifies and expresses the systems he put in place surrounding the balance of customer inquiry to product building and growing the engineering team.
Former Tech Lead at Xendit
Sydney Russakov, Senior Product Manager at LinkedIn, shares how she aced her role as a new PM in a different team.
Senior Product Manager at LinkedIn
Prasad Gupte, Director of Product at Babbel, shares how he drove innovation through structure, collaboration, and autonomy.
Director of Product at Babbel
Kirk Gray, VP of Engineering at McGraw-Hill, recalls his experiences performing major reorganizations of departments, including successful techniques to ensure a smooth transition.
VP Engineering at McGraw Hill
Priyanka Naik, AVP of Product and Technology at J.P. Morgan, shares her plan to bring a product to execution as the first product hire in a startup.
AVP - Product and Technology at JP Morgan
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.