A Brief History of Product Management: Starts With a Spark
Product management was originally seated in marketing but has evolved. It's still misunderstood but it's now getting the recognition it deserves with product people...
When we plan out our lives, it’s always a balance between our immediate needs and our distant objectives.
Our product plans are no different. We have a pile of things that must happen soon to address immediate customer demands (and complaints) and keep up with the competition. But there are also big-picture goals to extend the product suite, attack new markets, and support emerging technology platforms.
Creating a product roadmap containing both sets of plans might result in a document that’s super specific on the left while being fuzzy and amorphous on the right, which might be confusing to some viewers. That’s why trying to cram everything into a single artifact might not be the best approach to mapping out your product’s future.
Short-term roadmaps have different objectives than long-term ones, which is why it makes sense to split them up. The former is a summary of very real, tangible goals and the marching orders to make them happen. The latter illustrates the vision for where the product will/might eventually end up.
Short-term roadmaps may not be guaranteed. However, there should be pretty high confidence that what’s included will not only ship but likely ship in the same order and time frame described in the document. Obviously, things happen, emergencies arise and priorities may shift, but those should generally be the exception to the rule when it comes to this roadmap.
Long-term roadmaps are less about specific plans and more about storytelling. They paint a picture of where the product might go and illustrate the current thinking on product strategy and big-picture prioritization. They should never be taken as set-in-stone plans. Instead, they are intended to serve as a communication tool to create internal alignment, excitement among the customer base, and an indicator to the industry that you’re planning to do more than just tweak and optimize the existing set of functionality.
Because long-term vision creation and short-term planning vary in their scope, specificity, and certainty, there’s a strong case to be made to break them up into two separate roadmaps. They really represent two different layers of the Planning Onion. Not only is the content itself different, but so are the potential uses for these documents.
A short-term roadmap is a handy reference for engineering, UX, customer service, sales, and marketing, who can all reference these tactical plans when thinking about their own activities and dealing with customer inquiries. A long-term roadmap is far more useful for the executive team, fundraising, board meetings, and big picture strategic planning exercises.
While timeframes vary from industry to industry, a short-term roadmap often covers what the product team is planning for the next three-to-six months. These items can be fairly specific in nature—since the team should have a pretty good sense of what they’re building in the coming months—and with vetted levels of effect from engineering they can be slotted into approximate release windows with some level of certainty.
One advantage of a shorter horizon is the accuracy that comes with planning for the near term; it’s much easier to predict the immediate future and make commitments than it is to project things out a few years in advance.
A short-term roadmap should include dates, even if those are likely to change a bit, as they provide an anchor for each major release or milestone and provide a sense of scale for the document. Whether you show the dates or hide them depends on your audience; while it may make sense to display them internally, revealing dates to customers and prospects may be interpreted as a commitment versus a goal, which could lead to some unhappy customers if you don’t ship exactly when the roadmap said you would.
Of course, whether individual features should be included on a short-term roadmap versus limiting things to themes and milestones is a potentially tricky call; the more specific a roadmap is, the more value it offers to the viewer, yet it is far more likely to be inaccurate.
If you have a ton of confidence in your short-term deliverables, then calling out high-level features as milestones for a particular theme may be the right move, but if you’re uncertain then stick to a higher-level view. This also gives you the flexibility to shift individual features relating to a particular theme around if there’s new information that justifies a shift in priorities or if the implementation details inspire some reshuffling of the order.
While short-term roadmaps shouldn’t be a laundry list of features, they can cover the goals those new features are addressing. This provides context for the viewer about what these themes are intended to accomplish.
Equally important to what is ON your short-term roadmap is what’s NOT on it. We all have product backlogs a mile long and no shortage of feature requests and “nice-to-haves” lurking in our inbox—excluding certain items communicate to everyone that those things aren’t going to happen within the horizon of this roadmap, which is critical for everyone to understand.
The short-term roadmap should be updated as often as necessary to ensure it accurately reflects the current thinking and expectations. While no one should expect there to be zero changes, there should be a fair bit of confidence that the latest version will turn into reality so it shouldn’t stay outdated for long.
In an agile world full of dynamic, data-driven decision-making, creating a roadmap plan for two or five years out may seem like a fool’s errand. But in many ways, the items on a long-term roadmap are far more significant and important than what you’re planning to knock out in the next quarter or two.
A long-term roadmap takes the product vision and lays out a plan for how to get there. It turns theoretical into something plausible, with a loose timeline for how big dreams and ideas can actually become something real.
Unlike a short-term roadmap, longer-term ones don’t require the same frequency of revisions and updates; if your vision is changing more than twice a year, you’ve probably got bigger problems than an outdated document. Instead, long-term roadmap updates should be an output from vision and strategy work that results in new findings, conclusions, or decisions reached by the product team and/or executives and board members. It can be used to secure buy-in to that vision and strategy from stakeholders and contributors alike. Check out our other blog, 37 Tips to Creating a Roadmap that Aligns Stakeholders for even more on the subject,
Because this roadmap is updated infrequently, a new version probably deserves an official presentation and review as well, outlining what changes were made and the rationale for those decisions. It’s a great opportunity to remind everyone in the company what the product is trying to eventually accomplish and how their immediate efforts and day-to-day activities relate to that vision.
It should also be clear that the long-term roadmap is not a series of deliverables or commitments the product team is promising; the horizon is far too distant to assume any particular item will happen at all, or at least when it is currently penciled in for. The long-term roadmap is about the overall vision, not a release plan.
Whether reviewing a short-term roadmap or a long-term one, this document is one of the few tools product teams have at their disposal to command the full attention of their audience. They communicate, educate, illuminate, occasionally infuriate, and often spark debate, as everyone seems to have their own opinion on priorities.
Maintaining two distinct roadmaps, one more tactical and another that delivers the long-term vision creates a clear separation between “what’s going to happen” and “what we might like to happen.” This bifurcation limits extraneous feedback and maintains focus on the varying purposes of these different artifacts.
Both types of the product roadmap should still be generated collaboratively, soliciting opinions, data, and market intelligence from relevant parties across the organization and from the customer base. Neither should be created in a corner by a lone wolf PM who thinks they alone know what’s best for the company. And every element of the roadmap requires a clear reason for being and comes from a defensible position.
However, by keeping the short-term and long-term roadmaps separate, participants in the planning process come to the table with an appropriate context. Discussions of what should happen in Q2 versus Q3 are much different from what the company believes will be important four years from now.
So don’t fall for the trap of trying to fit everything into a single page. Give each roadmap some room to breathe and serve its intended purpose.