Yes, your agile team needs a product roadmap

Today’s article is a guest post from our friends at ProductPlan. Enjoy!

Just because your organization has adopted agile methodologies doesn’t mean you don’t need a big-picture strategy and a high-level plan to transform that vision into reality. But often, agile practitioners wave off the notion of a roadmap, claiming that it flies in the face of the agile approach—even if they’ve proven valuable tools. You may wonder then,  

Why the resistance to product roadmaps?

In our experience, it’s usually because the product roadmaps these folks envision are feature-by-feature chronological breakdowns that suck all the flexibility, creativity, and ability to react out of a product development organization. If every enhancement and improvement is already plotted, what’s the point of using a methodology whose fundamental benefit is nimble and opportunistic? First, let’s look at some misconceptions and why they’re inaccurate.

Misconception #1: Agile means there’s no long-range plan

While a purely reactionary approach would benefit from the agile methodology, a few companies don’t have a strategy in place. Who would fund a company whose pitch to investors is “we’ll figure it out as we go along?” Every organization needs some guiding principles and objectives to drive downstream decision-making. Those may change and evolve, but with no big-picture plan in mind, the company will be overly reactionary and appear to simply be flailing and chasing possibilities instead of marching toward a particular goal.

Misconception #2: Roadmaps are too specific for agile

While it’s true that some roadmaps are specific and prescriptive, calling out individual features and enhancements to be added in a very particular order, there are plenty of roadmap formats that are far broader while still being useful.

Misconception #3: We’ve already got a product backlog

While a product backlog is a phenomenal repository that can be groomed and mined for new features and enhancements, it doesn’t replace all the value a roadmap can bring. Are you going to show your customers your backlog? Will you tell your CEO to log into Jira and determine what they can expect to ship in the next quarter?

Choosing the right agile product roadmap

Devising a roadmap that complements and informs the agile development process is keyed on selecting the appropriate type of roadmap. Luckily, there are plenty to choose from these days—our personal favorite is a theme-based roadmap. Theme-based roadmaps tackle product enhancements at a higher level—rather than listing a bunch of specific items—while still leaving plenty of wiggle room and flexibility during the implementation stage. It does the job of prioritizing themes (based on the order they appear on the roadmap, or whether they appear at all) and still communicates an overall vision and general path of how to get there. A theme-based roadmap will focus on general customer problems to be addressed or goals to be achieved instead of individual features or enhancements. Contained within those themes will be a number of items that can be tackled via traditional agile methods. For example, when the roadmap indicates “Improve user onboarding,” the particular enhancements could include social media profile integration, reducing the number of steps to get a user up-and-running, and contextual help pop-ups and tutorials. Those specific items could be prioritized out of the product backlog based on what will have the most impact on meeting the goal of this particular theme. This happy medium still gives the company a general idea of where things are going while leaving the details of selecting specific enhancements and implementation priorities to the agile team when a particular theme is being tackled.

Adapting to life with agile-friendly planning

Based on the background and previous experiences of various coworkers and customers, your new roadmap philosophy will require a little education and a lot of communication to be successful. Here are some tips on making it work for everyone.

Set expectations: what your roadmap is and isn’t

Since everyone likely has different ideas about what a roadmap is “supposed” to look like, you shouldn’t just drop this into everyone’s inbox with no explanation. Start off by explaining the roadmap’s format and what it should—and shouldn’t—accomplish. Your roadmap will give stakeholders and customers a big picture perspective of where the product is headed and how it’ll get there. Your roadmap will align with key KPIs and the larger company strategy and will have a high-level timeline that sales and marketing can plan against. Your roadmap won’t be a laundry list of every single feature that will be implemented over the next 12, 18, or 24 months. It won’t include 100% of what may be built and shipped during the timeframe covered. It is not set in stone.

This is the plan—until the plan changes

Just because a roadmap is in place doesn’t mean product development can’t react to user feedback, customer needs, market changes, and strategic pivots. With a communal understanding that things may get shifted around, scrapped altogether, or delayed to pursue new opportunities, the roadmap can still set guideposts without locking anything in.

Overcommunicate

But to make that successful, communication is key—once people see a roadmap, they will expect those things to happen unless told otherwise. So, if themes change or priorities shift, everyone exposed to the roadmap should be made aware of any updates going forward. This avoids surprises and keeps everyone in the loop. The roadmap should also be revisited as new information is received and corporate strategy evolves. It’s the roadmap owner’s job to make sure it properly reflects what is most important to the product and the company, and you shouldn’t expect anyone to tell you it needs to be changed based on new developments. That said, the roadmap shouldn’t be constantly changing. By sticking to high-level themes, the minor details and small learnings informing specific feature decisions or implementation particulars don’t need to surface at the roadmap level.

A beacon during times of indecision

The roadmap isn’t just a communication tool, however. It can also be relied upon when teams aren’t sure what to do next or are grappling with prioritization challenges. The strategy-aligned themes of the roadmap can be the lighthouse in the fog, guiding teams toward investing in features that will have the biggest impact on the key goals that drove the roadmap in the first place. Having a simple visual artifact to refer to can level-set the team and provide a bit of structure as they debate the merits of various options and how they relate back to the business's overall goals. It’s a nice reminder of the “why” while everyone is worrying about the “what” and the “how” pieces of the puzzle.