Leadership and Roadmapping

Managing a roadmap, and the internal (e.g. sales) and external (e.g. customers) expectations that go with it, is vital. A number of questions must be considered. How far out do you plan? How do you make sure the plan is realistic? How do you measure success? How do you juggle input from customers, engineers, sales, and the general market?

This is my general philosophy on roadmapping, specific techniques I use, and tactics that drive process and enable leadership to build great products.

My Approach to Roadmapping

In discussing roadmapping, I will fix two variables, for the sake of a simpler discussion:

Let's assume that the primary objective for a given product is always to maximize the bottom line of that product's P&L over the long-term. I understand that this is not always the case, as leadership may have strategic goals for a product in addition to or instead of profitability, and in such cases, the ship needs to be pointed in that direction, instead.
Let's also assume that I have complete autonomy, to choose tools and work flows. Obviously, this isn't always the case, but conceding this will save numerous disclaimers and caveats below.

I consider a product roadmap to really be two documents that are maintained in parallel:

Goals Timeline — A list of tangible, measurable, useful (to the product's performance objective, which we're assuming is profitability) goals. Each goal is assigned a deadline, giving the opportunity to measure actual performance against the goals and see which are achieved and which aren't. This document clearly defines where the product is supposed to end up — not in terms of arbitrary features (of unknown value) but in terms of tangible results.
Feature Bullpen (Scrum's backlog) — This document is a comprehensive list of all potential features, refinements, or redesign/refactoring projects. Each item on this list will be fleshed out to varying degrees and may include notes about business value estimates, time estimates (for development), questions that must be researched/answered before the item can be properly valued or estimated for time, etc. As new items are added to the list or additional clarity and insight is gained regarding specific items, the list grows and reorders, allowing certain items to bubble toward the top, based on which are most likely to offer business value for resources invested.

This format of roadmap allows for accountability on actual business value objectives and timelines (something that may or may not be disclosed to stakeholders outside the company), and it shows all stakeholders which features are most likely to ship in the near future. But no commitments are made to timelines for specific features.

These two documents — the goals and the features lists — join into one, little by little as time passes. By keeping the goals timeline and feature bullpen up to date and clear, strategy can be developed based on both analysis of information available and judgement (which becomes dramatically more reliable with experience on a given product or team).

As each iteration/sprint/cycle of development is planned, the strategy is developed by choosing the right items from the bullpen that can be assigned realistic target metrics (if not measurable impact on sales or expenses for the product, at least a target for adoption/usage rate, improved customer survey results, improved sales team survey results, etc). The objective is to choose the right items, which can be developed in the time allotted, and can keep the product on track to reach the upcoming goals, if they perform up to their individual target metrics.

The timeline for goals can extend out as far as is useful, given the stability of the market, maturity of the product, etc. Regardless of how far out the goals are projected, I find the most value in committing to defined goals and deadlines only within the next 12 months — as farther out than 12 months leaves too much time for changes (in the product, the market, the team, etc) to happen, which cause for abandoning a long-term goal or at least editing the parameters and deadline.

There are numerous tools that could work well for maintaining these roadmap documents. In the past, I've used Basecamp, but even a shared spreadsheet could work fine. Any tool that allows a single copy of these documents to exist and be visible to the right stakeholders at the right time is great.

For me personally, communicating with the appropriate engineers about the technical aspects of features being considered for development is a vital step in understanding the implicit cost of development. Only by weighing that against the expected business value offered by the feature can I reach a conclusion about how truly valuable a feature is.

And similarly, when it comes time to actually commit to a basket of features to develop during an iteration/sprint/cycle, I think you need to work toward consensus (in most, if not all cases) among the team members for what the team is committing to accomplish during that time.

The key to managing expectations of all stakeholders, in my experience, is to communicate clearly and often with them and to use face-to-face conversation with them for these discussions/updates, whenever possible. Building personal rapport helps the various stakeholders to trust my character and concern for their best interests. This is invaluable in the event that a feature takes longer to roll out than they would like, and it enables calm and effective conversations about the reasons causing such a situation.

Similarly, I work to fully understand the feedback that comes from sales (and thus sales prospects, by proxy), customers, engineers, and marketing. They have a perspective that I don't and can't on my own. I rely on internalizing and synthesizing their points of view, in order to develop proper judgement and insight for product decisions. And making sure the stakeholder feels understood when they've offered feedback is vital at this point.

Once I am confident I understand their feedback, I thank them for it and make sure they understand why and how much I value it. I then assess the feedback through the lens of ROI, against the objective for the product passed down from leadership (for the sake of discussion, profitability). At this point, I can update the roadmap (along with any unofficial, personal notes I may be keeping) accordingly. At that point, I find it's valuable to go back to the same stakeholder and summarize for them the conclusion I've come to, emphasizing that my focus is steering the product toward the objective laid out for it — to properly set the stakeholder's expectations accordingly. If they felt appreciated and fully understood, at the time they gave the feedback, they are very likely to be understanding of my explanation as to why I'm planning how I am.