How Clear is Your Roadmap?
So you have a roadmap that is guiding your organization. Work is getting done, product is shipping to market, so, all is well right? Not necessarily. Here’s a litmus test: approach three people across your organization (one of the engineers, one of your stakeholders in marketing or sales, and one of your senior leaders or executives), and ask two questions:
WHAT is the product development organization building over the next 3 months?
WHY is the product development organization building those things?
If you get consistent answers across the three people, congratulations, you should celebrate! If not, you might take a step back and consider whether your roadmap is actually clearly articulated across your entire organization.
There are a ton of articles out there about the tools you can use as a Product Manager to manage your roadmap, and a ton of opinions out there about roadmapping best practices. This, hopefully, isn’t yet another one of those articles - and here’s why: I’ve worked in software for 18+ years for 8 companies of various stages of growth and across 5 distinct industries, and there isn’t one silver bullet tool and/or approach to roadmapping that would have worked across those 8 distinct companies.
What I have learned over the years is that effective roadmaps and the processes surrounding them come down to what the team, the stakeholders, and the senior leaders find most clear. The people I worked with at these companies all had different collaborative definitions of what “clear” means, which had an influence on the processes and tools we used to manage and visualize our roadmaps.
For some organizations I’ve worked for, roadmaps were managed directly in the agile software management systems we used, such as Jira/Confluence, Team Foundation Server, or Rally. For other organizations, we used multiple tiers of roadmaps: one granular roadmap for the teams building the software; one strategic roadmap for senior leadership and executive teams, and one thematic that we used externally for partners and customers. And, for the early stage startups I worked for... Google Sheets worked just fine for our teams of less than 15.
Rather than choosing your roadmapping tools and processes from external recommendations and/or “industry best practices”, I recommend you focus on the unique individuals you work with and frame the question around clarity. Ask yourself, and your colleagues, “What do we need to do so that everyone across the organization will answer these two questions consistently: ‘WHAT are we building over the next 3 months and WHY are we building those things?’”
I offer some advice to help you improve “clarity” with your roadmapping: repeat yourself a lot and do so through a variety of channels. Remember, humans make up your organization, and humans miss a lot of information on any given day, and/or they all have unique ways of hearing or processing things. So I’ve found that Product Managers must frequently repeat themselves when it comes to communicating the WHAT and WHY of the roadmap, across many different channels and/or venues. Visual roadmaps with strategic themes, Table-based roadmaps with granular details, team meetings or organizational presentations in which the roadmap is verbally shared, etc - these are all examples of how you can communicate your roadmap to your organization that maximizes the chance of getting through to the various people within that organization.
So if you’re a Product Manager or a leader of Product people, consider just how clear your roadmap is for your organization, and whether celebration is in order, or a “rolling up of sleeves” is in order.