I talk to a shocking number of Product Managers on a regular basis who are exasperated at their company’s approach to roadmapping.
Some companies refuse outright to have a roadmap, instead opting to put to paper only what they can commit to in the next few sprints – ie. a release plan or project plan. These poor product managers spend most of their time either firefighting or building whatever tickles the fancy of their CEO/noisy sales team/eager developers, etc. They constantly struggle to make the case for building anything with long term value.
Others take the opposite approach, and insist on having a structured, committed
roadmap glorified Gantt chart to guide the team across every obstacle and iteration in the next few quarters (or years!). In these cases, the Product Manager ends up acting as a project manager. Realistically, it means adding all sorts of buffer and hoping for the best as each month crunches by, all while constantly having to make excuses for the roadmap’s inevitable changes in scope and time.
Why bother with a roadmap?
Many companies do realize the importance of creating a product roadmap. An effective roadmap is a carefully designed document that communicates the product vision and the areas of focus that’ll be tackled to get there. Its purpose is to show the development, sales, marketing, and other internal teams in the company the vision for the future of a specific product or product line. It will set broad goals and provide the steps necessary to achieve them.
According to an article in Pragmatic Marketing Magazine, “As your company grows, different departments will be involved in executing different elements of product delivery (e.g., marketing, distribution, development). A product roadmap keeps everyone aligned by defining a common vision for the company’s direction.”
The many benefits associated with a product roadmap are what make them essential. With a good roadmapping process in place, and a well-designed product roadmap, every company department, from sales to development, will work better. It provides the product team with a valuable artifact for constructive conversation, both at the inception of the roadmap and in follow on conversations as each month passes and the roadmap is reviewed. The very nature of the roadmap should outline the product vision effectively enough to allow teams to work with relative autonomy, and ensures that a cohesive, valuable product is being built.
Importance of flexible roadmapping
Finding the balance of detail on your roadmap is a bit of an art, but is absolutely essential. Over time, your roadmap format will certainly change, accounting for changes in the team, the market, the available technology, and more.
Flexibility in Time
Product release dates can change, and those ‘set’ months or quarters in advance certainly will. Instead of setting exact dates as releases, set a series of ‘time horizons’ such as ‘Current’, ‘Near Term’, and ‘Future’, or at the most granular, quarters for the upcoming half year, half years for the following couple of years, and if your roadmap extends that far, granularity at the year level.
This approach allows you to have flexibility to switch around projects in projected time horizons, without having to rejig your entire roadmap. Each time you have to realign and re-communicate a new roadmap, you need to instill understanding and buy-in for the latest changes – this will often kick off drawn-out discussions about, for example, the order of Project X and Project Y, even though both are realistically not going to get touched until the following year anyway (by which time, a lot could have changed, so the conversation was for nothing!). Over the course of months, the team can change, technology can change, and development can have unanticipated challenges. Setting dates based on time horizons rather than actual release dates helps keep the focus on the wider picture, delivering towards the product vision.
Flexibility in Scope
The reality is, some companies have to deliver to dates. There’s a signed off project, or an important conference coming up, or a seasonal marker – whatever it is, it shouldn’t prevent your company from being able to work to a flexible roadmap.
As the old adage goes: “Quality. Speed. Price. Pick two.”
In the case of signed off projects, with a set scope and a set time, there’s not much you can do besides hunker down and deliver it. For this, you will need a project plan and a detailed understanding of what needs to happen at each stage to ensure nothing slips. But this isn’t a product roadmap, or even part of the product management process – this is project management and requires a project manager hat (I speak to a lot of product managers who find themselves stuck in this situation, simply delivering on projects instead of building and iterating based on the product vision). As the old adage goes: “Quality. Speed. Price. Pick two.” If time, scope or quality starts to slip, be prepared to pull in extra resources, even if it means taking them off other areas of the roadmap… another reason to build in flexibility in that roadmap.
For projects with a set time, the only way to even estimate a future delivery date, without spending tons of effort in sizing, scoping, and planning a detailed project plan for it, is to remain flexible in scope. Your roadmap shouldn’t be made up of detailed features outlining exactly what should be delivered. By the time you get to the point of starting on that feature, the entire product or market may have changed around it, meaning all that spec’ing effort was for nothing. Instead, outline ‘areas of focus’ and provide details of the problem you intend to solve as part of that deliverable. For example, instead of promising Facebook Connect in Q4, outline it as ‘Social Connect’ – by Q4, it might turn out that LinkedIn is more important to the business, or MySpace made a comeback. You’re still solving the same problem, allowing people to connect via the social networks they use the most, but you’re not stuck breaking old promises.
Reviewing your Product Roadmap
Naturally, the further out a potential area of focus or deliverable is on the roadmap, the more flexible on time and scope you’ll need to be.
If you review your roadmap on a monthly basis, you can add extra granularity to the areas that are more impending, shift around deliverables based on what you’ve learned about your team, the technology and the market in the last month or so, and deliver a roadmap that’s subtly different, but not a massive change from what the team was already bought into. With a flexible roadmap, you’ll stop that trend of simply shifting all of the items to the right by 1 month in order to adjust for whatever new projects or slowdowns cropped up in the last month. You’ll have a clean, concise, and useful roadmap as an artifact for discussions on what really matters – delivering on the product vision.