Product Roadmaps: Real or Ridiculous?
“Plans are nothing, planning is everything,” at least that’s what Dwight D. Eisenhower said. The plans will change, but it’s in planning that you learn, improve and prepare. Roadmaps are the best tool available to product managers and companies to help with planning. Roadmaps can be a divisive topic for product leaders and business owners; let's dig into it a bit. My perspective is based on the last decade or so working on enterprise software with ~7 of those years product-focused.
Agile Product Management allows businesses to build products with an iterative customer-centric approach. The flexibility, collaboration and improved value delivery it provides are key to creating complex products like software. Agile, Scrum and Kanban are frameworks that can be applied to any business context but have their origins in the world of software. These frameworks can be applied and followed strictly at first, then adapted to fit the organization's needs and the people who are doing the work. If you’re not familiar with these, think of them as “rulebooks” designed to move work (value) from beginning to end (release) as painlessly as possible.
Traditional project management processes would have all of the planning done up front and in immense detail too. Think more like how you blueprint and plan a skyscraper or vehicle. These methods require having all of the knowledge upfront. In other words, pursuing a traditional or waterfall process is similar to saying, “I know everything and will not learn anything about this project once we get started,” which in most cases related to software product management is less than accurate. We’re always learning more about the technology, marketplace, customer needs, changing laws and so much more. This process can still work but is maddeningly slow and tends to fall short of customer expectations.
Roadmaps in Software are used in different ways by different organizations. There’s not exactly a “right” way to use them, but there are many wrong ways. Used as a conversation and planning tool to outline the vision and direction of the product or company over time, they can unite a company and show a customer or leader a clear path of progress (albeit promised). Roadmaps are a necessary piece of the agile product management game. In agile, the planning is short-term and based on two-week intervals, but there’s still a larger need for direction and a need to look toward the product’s future which is where roadmaps come in. They can be set up quickly and adjusted regularly to meet the current needs of the business based on customer feedback and other variables.
Agile Product Management and Product/Project Management in general is, in a sense, “guiding” projects/products through a journey toward an ideal yet unknown destination. With all of the feedback, tech debt, new epics, customer requests, bugs, innovation and more to juggle in the day-to-day, a roadmap acts as an information radiator (thanks PMI-ACP for that term!), relaying a whole lot of information about the past, present and future of the product in a quick accessible format. Anyone can come to grips with a roadmap after a moment or two; it’s clear what’s being worked on and what’s coming around the corner. This clarity allows the real work to be done, prioritization and other conversations around the work itself can happen to reach company goals and achieve the vision.
Roadmaps are called roadmaps for a reason. They are the map to success and a one-stop shop to see where a company is headed. A roadmap is not something that should be made and contained in a secret product-only meeting held under the full moon. They should be shared with the whole company and easily digestible. The transparency this brings promotes a better company culture overall and gives every team a sense of belonging in the big picture as well as confidence that there is a big picture.
Goals can be set and understood quickly and plans can change without too much concern or discussion when everyone understands the roadmap. There’s nothing wrong with a cohesive and aligned organization at all. There’s often a “roadmap within the roadmap” for the product team that includes the epics and pre-requisite work and stress that goes into prepping an item for the team. While important for sure, most other departments and leaders looking at the roadmap don’t need to know the specific epic numbers, their user stories, and estimates. This is where roadmaps can be wonderful for strategy and organization; a product team can slice pieces of the roadmap up for analysis and ask the questions needed to make sure “enough” is planned. This streamlines the flow of work to the dev team while giving them a good heads-up on it and enough time to weigh in with insight and wisdom (as all devs should).
Might sound like I love roadmaps right now? Well, I do... But they can be awful if used incorrectly and sink a product and/or a company culture. The first roadmap sin is to leave them unchanged. A roadmap is not a set-it-and-forget-it tool, they need to be fed and maintained to thrive. If the roadmap is not adapting, the value delivered will not be as valuable as it should or could have been. Nobody in product management sees the future and knows everything (yet). As you learn, put that wisdom into the roadmap.
In rapidly changing industries like software, or in my niche of cannabis software, there will always be unforeseen issues like new laws or changes in electronic payments and other technology that keep you on your toes. A roadmap can be rendered useless by new laws or marketplace shifts. You want to be able to shift with the marketplace; otherwise, you’re building yesterday’s solution. That being said, it’s not like balancing flexibility with structure is easy; it’s an ongoing task to find that balance and core to agile product management (The Planning Paradox). Excessive rigidity can lock in the roadmap and put a damper on innovation, while too much flexibility can create a different kind of chaos. That balance comes with experience as the product manager, leaders and other teams get comfortable with the tool.
Roadmaps should be thought of as a conversational and planning tool, not something to hang your hat on. In other words, don’t set unyielding expectations around a roadmap. It’s necessary to embrace the potential for change. Regularly reassess roadmaps in a small group including the product team and leadership then again with the company overall. Set a meeting cadence for this and stick to it to create a common language around road mapping and a realistic understanding of the work to be done and the need to have a flexible plan vs a supremely detailed one. The more details the quicker it’ll start to feel outdated and not worth the effort to maintain. Find the balance unique to your team and company.
Once a near-term roadmap (2-6 months) is being used within a company, more holistic roadmaps can be created to have one year and even three year conversations with a heavy grain of salt. We know these will change when planning at the bigger level, but when done loosely it can create a sense of clarity for the future and help again with alignment and the long-term trajectory of the business. I’m not a fan of road mapping past 4-6 months, as it’s too abstract there. Certain goals need that longer runway, but most do not.
In summary, roadmaps are your friend if you’re in software and especially so if you’re an agile product manager. In fact, if you’re an agile product manager roadmaps are your best friend. They guide the work from a high level so that you can focus on the iterative planning that needs to be done in more detail. With the added benefits of aligning the company and promoting a sense of transparency, you cannot go wrong with a roadmap. Unless you set-it-and-forget-it that is (don’t do that).
To begin using roadmaps more effectively for your product, find a tool of which there are many (Roadmunk, Monday) and mock one up as your starting point. Keep continuous improvement in mind and start getting feedback. I use a roadmap on my projects regularly and recommend keeping them “lighter” for conversation and prioritization with other teams and customers but make sure your items are mapping back to epics to detail and describe the work to be done. With wise use of this tool, a product manager can keep their product on a path towards success and business leaders can quickly assess the trajectory to make changes as needed.