Software launching requires strategy, but strategy alone is not enough. There must also be a system to match up strategy with day-to-day activity, managing development and launch as a project. This must be sufficiently adaptable as to function as a constantly-revised, living document, not a series of instructions that cease to be relevant as products evolve and plans change.
In this post, we’ll look at how roadmaps work, how to get the best out of them, and how to create one that works, as well as some of the pitfalls and problems. First, though, why do you need a product roadmap?
Why do you need a product roadmap?
Product roadmaps explain the terrain, challenges, and route between where you are now and the launch you have planned. They’re how the product strategy becomes a reality at each step.
A product roadmap does what a roadmap does: helps you plan the trip. Importantly, it identifies known or likely challenges ahead of time, letting you plan to solve them relatively dispassionately rather than cope with them when they become impediments or crises.
Product roadmaps will include parts to play for almost everyone in the organization; therefore, almost everyone will have both exposure to the roadmap, and input. Roadmaps can be an important way of getting everyone on the same page, and soliciting buy-in from stakeholders. Handled properly, this is a two-way process in which feedback from sales, marketing and support help developers manage and design the roadmap better. The result should be a shared, agreed-upon plan for the direction of the company.
How product roadmaps evolve with products
Products change with time, becoming more complex and multifaceted. They may pivot during development, as you realize your core customers are not who you thought they’d be or your most valuable functionality is being used off-label for something totally unexpected.
This evolutionary process is more or less inevitable: whether you’re a startup roadmapping your MVP or a $10m MMR SaaS roadmapping new features, the process shares some similarities. Your plan will change; as you engineer and develop, you’ll meet obstacles and opportunities.
However, there are differences too.
Horizon: predicting the future
Startups have a harder time predicting future requirements and opportunities for their products, because they have far less data of their own to go on. If they’re launching truly disruptive products they’re likely hoping to change the future themselves, often in unpredictable ways. How should YouTube have planned for the media landscape of 2010, with the growing centrality of YouTube itself, when they launched in 2005?
Larger companies, by contrast, often have roadmaps that extend further into the future, based on the data they’ve collected for themselves. With established client bases and market share, they can make their plans in the longer term.
Frequency: priorities vary by growth stage
Small, new companies often find they need to ‘always be shipping.’ Larger organizations need to put out new features more carefully; it’s more important to exhaustively test for bugs when you have 10 million customers than when you’re trying to get the first 10.
Dependencies: move slow and don’t break anything
Startups, famously, can afford to move fast and break stuff. They’re not attached to a network of partners, clients and customers by a web of APIs, SLAs, integrations, and back-compatibility obligations. Roadmaps for a new feature that will detonate ten years of back compatibility need to be complex and carefully laid-out, taking account of the wishes and capabilities of related organizations and stakeholders that may be several degrees of separation away from your company. MVP roadmaps don’t need any of that.
Goals: growing complexity
Most startups have quite simple goals, seeking to gain traction, prove viability or achieve growth. Enterprises have more complex goals that are more diverse, interrelated and strategically nuanced.
Planning a product roadmap
The planning process inherently requires input from a range of stakeholders. Anyone who has ever partaken of such a process is now recoiling in dread, recalling the old saying about a camel being ‘a horse designed by committee.’ Everyone’s suggestions can’t make it onto the roadmap. So how should companies filter suggestions?
- Does it have value to users? If not, leave it out to save space for something that does.
- Is there evidence to support the idea that it has value to users? Go with what the data supports here. If there’s no proof, default to leaving it out.
- Who will be responsible for it? What’s everyone’s responsibility is no one’s, and winds up not being done. If no one wants to take ownership of it, maybe it shouldn’t be on the map.
- Does it make sense in terms of the rest of the roadmap? You wouldn’t plan a trip from California to New Mexico and throw in a pitstop in Maine, it doesn’t fit. Does the suggestion synergize with the other parts of the roadmap or go against them?
Features and prioritization
Roadmaps will always have more potential destinations than you can actually travel to. Product roadmaps invariably contain many more features than you can possibly hope to actually include. Even where all these features are desirable, some will have to be sidelined to allow the roadmap to actually function. It’s not a wishlist, it’s an itinerary, so you’re often in the business of cutting not building.
One option is the ‘MoSCoW’ prioritization framework.
But this might not go deep enough. Another way to approach what should be on a roadmap is to look at cost-benefit analysis for the activity. For instance, it’s almost always preferable to focus on fixing bugs and improving existing features rather than on releasing new features. And when you’re creating a new product, it’s usually preferable to ship a small number of features that work stably rather than a larger number that are unstable.
Multiple products
So far, we have looked at individual features or products. But what about roadmapping multiple products?
Multiple-product roadmapping is a challenge from the purely practical perspective; it’s hard to arrange and hard to represent on a page, in a deck or on a project management app (just one reason why you probably shouldn’t use one).
Aligning messages and timetables for multiple products presents challenges of its own. With multiple product management teams and managers involved, each with its own priorities, internal cultures and plans, conflict becomes more likely and complexity increases exponentially.
Finally, the products themselves might be at different stages of development. Now your roadmap is less like a plan for a road trip, more like a railway timetable or air traffic control. Handling this level of complexity is more than you can expect from off-label tools. It requires specialist solutions.
Roadmap alignment
Roadmaps are as prone as any other form of planning, content and documentation to the proliferation of versions. Keeping one canonical ‘source of truth’ roadmap is crucial, but it then becomes a challenge to keep it up to date. And when there are multiple products or several features at different stages of development, the challenge becomes even more acute.
Part of the solution to this has to be the company, and particularly leadership. Expectations about the level of granularity, the structure, and even the color-coding and other basic visual aspects of the roadmap should be agreed on in advance, stated clearly, and enforced; otherwise, it rapidly degrades into a pointless time suck instead of a priceless asset.
The Agile roadmap
Traditional roadmaps were worked out long in advance, with deadlines and plans, and sub-roadmaps for specific departments. It’s easy to imagine how that went, but it’s not necessary, because there are still plenty of developers around today who can remember.
Now, those developers are often among the most enthusiastic adopters of agile roadmaps. The reduced tendency for the plan to disintegrate into a work of fiction upon contact with reality is a major selling point.
This is achieved by making the roadmap a living document, something that changes as goals and methods are adapted and product plans evolve. The final version of the roadmap may differ strongly from the original, but at every stage of the development process, it can be used to guide and offer direction.
Agile roadmaps look different as well as functioning differently, and they require different approaches to keep them functioning well. In particular, they require role-based permissioned access and changelogs to ensure only the right people can change them. You can build an agile roadmap without these features: you can do it with a #2 pencil and a piece of paper. But it’s more difficult and it rapidly becomes insupportable as complexity rises.
Roadmapping tools and solutions
The first tools most leaders reach for to create roadmaps are basic productivity tools like Slides or Powerpoint. Creating visually appealing narratives is relatively easy with these tools, and many leaders are already familiar with them from pitch decks.
However, it’s difficult to incorporate the requisite granularity and detail in tools like these, and there’s little opportunity to create living documents. When you do use a Slides or Powerpoint file in this way, the lack of permissioned access and underdeveloped annotation system soon make themselves known as problems.
The obvious alternative is project management software, which many companies are already using, and it is better than Powerpoint. But project management software is designed for managing projects. It’s not designed for roadmapping. At its very best it’s an imperfect fit with much extraneous functionality and some crucial functions missing.
The best solution is roadmapping software built for the purpose by software engineers who know what it’s like to use a roadmap — they used one to build the software.
AndPlus offers a product roadmapping service, helping our clients create effective product roadmaps, or creates them from scratch, resulting in custom roadmaps that let users adapt a living document as demands and requirements change.
However, AndPlus doesn’t merely provide tools for planning. Our long experience means we can provide effective consultancy as well. Our product map process is unique in that we begin with a degree of adversarialism, bringing a critical eye to features selection and helping to make sure the roadmap includes necessary features, not just those that made it into the plan. It’s not unusual for our clients to save 20% on a project scope budget after completing our product mapping process.
Takeaways
- Roadmaps are there to give a visual, intuitive structure to the process of developing and shipping new products
- Like a real roadmap, they do more than articulate strategy: they indicate routes, stop-off points and terrain that’s likely to be difficult
- Roadmapping that fits with the Agile development structure is preferred as a more accurate and versatile tool
- Off-label software designed for other uses introduces new difficulties into the roadmapping process; purpose-built roadmapping tools are better
