Creating focus within the chaos of roadmapping
When discussing product roadmaps, I often get asked questions like:
What tools do you use to create your roadmap?
How do you share the right level of detail with different audiences?
How do you effectively communicate plans?
While these are important topics in order to execute the roadmapping process, it’s important to focus on why we roadmap in the first place. The roadmapping is process in and of itself is critical, but all to often teams brush it aside and instead place their singular focus on the output.
Late last year, I traveled to India to work with a few startups. During my visit to Mumbai, I was captivated by the “flow” of traffic. I remember looking out of a window and seeing a bike, van, and car all approach the same spot of a 3-way intersection at roughly the same speed and at the same time. It looked something like this:
People were moving, cars were turning. But traffic just continued to flow. It was some sort of magical, orchestrated, organized… chaos.
As I continued to be mesmerized by this coordinated chaos, I realized that the traffic flow was merely a reflection of the culture and norms of the society. The drivers, pedestrians, and bicyclists were actually following a set of “rules of the road” that helped move everyone through the intersection.
Roadmapping “Rules of the Road”
Much like the literal rules of the road differ from Mumbai to San Francisco, every product team will have their own culture influencing and creating their “rules of the road”. That’s why there is no one-size-fits-all ideal roadmap to strive for; roadmaps will be vastly different between industries, companies, and even teams within a single company. Instead, it’s better to focus on the process of roadmapping. And that process your product team uses deserves as much energy and self-reflection as developing the product itself.
Processes and culture inform roadmapping, not the other way around.
Creating a roadmap won’t magically create the right product development processes. Instead, your team’s shared rules of the road are what will create the focus, consistency, and transparency that lead to a useful roadmap.
Practice Makes… Habit
In that Mumbai intersection, it was clear that the traffic patterns were developed over time through trial and error. Similarly, developing a roadmapping process that results in the best output for your team requires some amount of trial and error. But the continual habit of learning and iterating on the process will lead to an optimal “flow” for your team.
The habit of building and communicating your short- and long-term product plans helps not only to create clarity in your own mind, but it also helps align the entire team in the same direction. This is the most valuable part of the roadmapping process.
In preparing for battle I have always found that plans are useless, but planning is indispensable.
~ Dwight D Eisenhower
Product Planning Timelines
Product development and roadmapping are a continual process that require your team’s perspectives across short- and long-term time horizons. Each piece is interconnected — as the team completes sprint work, it will affect the larger projects in progress, your quarterly deliverables, and strategic commitments. To run away with my theme here, I’m going to break down each roadmapping time horizon into traffic analogies:
- Street Views. Typically, the most “zoomed in” view of the roadmap, it consists of the individual tasks that will be completed in a given sprint cycle. A sprint timeline is usually within days or weeks so that it has the lowest-level breakdown of work.
- Town Views. The next level of roadmapping could encompass weeks to months of work; whatever time horizon helps your team break projects down into discrete, predictable milestones. On the Square Invoices, for example, we use 6-week intervals to allow for adjustments on product features or experiments without having to wait to re-define a set of quarterly goals. Typically, we try not to change the scope of a project within the 6-week intervals. Anything not accounted for in the 6-week scope goes into the next cycle. (But that’s not a hard and fast rule for our team; it simply helps us stay as nimble as possible.)
- Country Views. Zooming out a bit further, we get to quarterly or semi-annual product commitment planning. Many companies use the objective and key results (OKR) process, but your team might use another goal-setting framework. Depending on the size of your company, this may be the right view (or level) of the roadmap at which you as the PM need to communicate, align, and get buy-in from your cross-functional partners in Support, Account Management, and other areas of the company.
- Global View. Finally, the most comprehensive vantage point involves the product vision which could span multiple years. This is where a strategic plan or a business plan outlines the market opportunity, customer needs, product value, and other long-term objectives. At Square, these plans are co-authored by the various disciplines involved in product development (namely, the design, marketing, engineering, and of course, product groups) so that the entire team understands how decisions we make throughout the year impact the larger goals we set for ourselves. We tend not to change our annual plans throughout the year. If anything, we may do a small refresher mid-year, but we otherwise we leave these plans alone because they provide a great marker (or road sign, if you will) for us to analyze our performance in our end-of-year retrospectives.
For your team, these rules of the roads may be different, and that’s completely fine. As long as your team subscribes to the same habits, the product development process can take whatever shape makes the most sense in your organization’s culture.
Just remember, roadmapping is a process, not a destination. Iterate on that processes just as you would for your products, with buy-in from your entire team so that you don’t experience stagnation, bloat, or pure chaos.