For those that have previously been involved in software development I’m sure you’d agree that the process is rarely one that can be done in a single hit. The need to enhance, improve, adjust or evolve an application over time will always exist.
It doesn’t matter whether your project build was undertaken on the basis of a waterfall or an agile development method; the same challenges still arise on an ongoing and frequent basis. User feedback comes in, scopes change, technologies evolve and designs become outdated.
As a solution to this ongoing challenge outside of the project delivery framework many people turn to software development roadmaps to help them. But what are they, what can they do for you and should you use one?
By way of explanation, let’s take the essence of a roadmap in an ideal world. With the assumption that we’ve taken delivery of our software application and it is in use. It may be an internal product or a SaaS product, it makes no difference because the roadmap can be adopted for a wide range of scenarios.
It is always the case that due to budget or time constraints there will be some things that the software doesn’t yet do. Those features weren’t critical to the overall core operation of the product but it is felt that user experience may be improved by adding them in at some point. Those features are perfect candidates for inclusion on your roadmap.
As you start adding these and other things into your roadmap you’ll be generating a chronological, linear route for the evolution of your product. Each enhancement on the roadmap should not be too precise but should give the overall high-level idea of what you’re aiming to deliver. They represent a vision for the product based on the overall strategy but without giving a total commitment nor any solid release plans .
You can draw this out how you like. Many people take pride in their roadmaps, and understandably so. Tube station, cartographical, linear and list are types that have been done before but - honestly - it’s the content based on thinking these things through that is the key.
OK, so here is where the real world starts to bite. But don’t be disheartened; the fact that you have or are considering a roadmap already puts you ahead of many that are ignorant of their benefits.
It is up to you whether you want to include timelines on your roadmap. Let me put that another way: you do not have to have a timeline on your roadmap. This might come as a bit of a surprise but I would urge you to seriously consider whether dates are needed at all. If they are required, how loose can you make them? Could a feature be delivered sometime in 2021 or Q3 2020?
Obviously there are benefits to having a timeline if you have critical business actions based on its delivery. It’s up to the roadmap creators to determine whether this is the case but this must also be balanced with roadmap flexibility (see below) and your team’s ability to deliver. Honestly, you can put whatever dates you want on a roadmap but if they are just another date that’s going to be missed there is no point and you might as well retain your integrity and reputation by not putting one on at all.
Just like your software development project, roadmaps should never be left unattended and ever thought of as done. Due to the inherently fluid nature of the software-product-market interface you’re going to need to keep a tight grip on where you put any development budget and resource. What might be an urgent need one day might simply vanish overnight.
It’s enough to say that the roadmap needs to be reviewed regularly. What regularly means in your world depends on a whole host of factors but arguably the test should be whether the roadmap is up to date when anyone looks at it. If you’re finding it a useless resource because of how stale or out of step it is then you need to up the review cadance. If you’re going to do a roadmap at all, review it. If you’re not going to review it, save yourself all the effort and don’t bother with the roadmap exercise at all.
So who should be involved in the roadmap production and review? The simple answer is that it should be as broad as possible. Here are some examples of possible roadmap influence from different departments in a larger company:
Not all saying the same thing are they? You get the idea. Those responsible for the roadmap are trading off the constraints and restrictions imposed by different areas of the business. The degree to which this is applicable to you depends on your stance on timelines (see above) and how critical the roadmap is for the wider business.
It’s quite possible for these discussions to get heated. After all, everyone has their corner to fight and wants their pet feature put in. With a professional team you shouldn’t have too many problems but, if it helps, keep in mind the following points:
It very much depends upon your team but you may want to get everyone together (either in the same room or on the same virtual meeting) rather than use shuttle diplomacy. One-on-one meetings can help align thinking and emailing can always be used to sound out people or to follow up.
One simple point that is often overlooked is to ensure that the roadmap remains accessible. Don’t create a hard copy and file it away. Instead, make sure everyone can find a digital copy that is current (always mark superseded roadmaps accordingly) and can refer to it.
Gain a point if you are questioning why your product users aren’t in the above list. Well, as a driver for change it is correct that they need to be involved. However, it’s worth seperating them out as they’re not really a constraint to the roadmap but rather the inspiration for it. Speaking to your users regularly is an absolute must for startups and some would argue for any business that wants to maintain a good product-market fit. Even internal company projects need to have some form of feedback mechanism.
The feedback that you get should ideally be in the form of a User Story and can feed into the Roadmap in two ways:
Firstly, it should appear somewhere in the feature list. If users are asking for the ability to change the colour of the app widgets and it falls within your product objectives then it stands to reason that it should be on your feature list. Having a feature list purely driven by user requests is not a bad space to occupy.
The second way the roadmap benefits from user feedback is by adding weight to existing requests. Your roadmap might treat features differently if one has only been requested by a few users compared to one that virtually every account holder has asked about.
Be careful about adding features purely based on user request weight, however. Remember back to the input we get from our software developers? That suggested that some features may be necessary to get somewhere else, or we may get a feature for free if we implement a related feature. In short, triage your roadmap carefully and don’t ever rely on a single metric.
So, should every feature that we want to implement be on the roadmap? I think the answer has to be no.
Chances are that your feature list will be growing almost exponentially if you have a product anywhere near production. For every feature that you add at least a couple of good suggestions will come up on how to vary or improve it. That’s no bad thing but if you try and implement that into your roadmap you’re going to find it an administrative nightmare.
Instead, understand that it’s perfectly okay to not have something on your roadmap. Indeed, “That’s not on our roadmap yet” is one of my many overused bits of feedback for enquiries. Make sure you see your roadmap as a realisation of your product strategy. Put the key parts into it that help to tactically deliver that strategy. Triage your features as part of your review process and don’t plan too far ahead.
Indeed, that brings us nicely to the reasons why roadmaps shouldn’t go too far into the future …
So making sure you build in some flexibility (ability to adapt and review the plan) and agility (the speed at which your plan can react) are real wins. Often these concepts are what separates a startup from a larger corporation. The former are often more flexible and agile and can therefore seize opportunities quicker.
At the strategic level, you might want to schedule regular roadmap reviews. This ensures team input happens periodically and your roadmap doesn’t simply become a document that you’ve ticked to say that you have yet nobody ever looks at.
Another option is to implement a continuous review process for your roadmap. Don’t consider the roadmap as ever being finished but instead consider it to be always evolving. Each feature on the list should constantly be reviewed by the collaborators and requests made for change. If you have agile development processes then this may already be second nature to you.
Either way, try to keep your collaborative teams efficient and knowledgeable. Make sure you have good reliable, up to date metrics for each department to query when making roadmap priority decisions.
To that end, you may find that having a roadmap that goes too far into the future is futile. Things will get less certain as they get further in the future. Anything past 2 months ahead is very likely to change so why bother having it on there? While there’s no set limit you’ll soon find for yourself that there is a balance between what works for you and your product versus what is up and coming and helpful for users to know about.
You don’t want to be in a position too often of saying to a user that something is on the roadmap only for it to be removed. Don’t be shy of reserving that right, however - it happens sometimes and indeed should happen for a healthy development cycle.
Sometimes there are questions around some form of automation for roadmap generation. Given the amount of knowledge that needs to be drawn together and reviewed it’s hard to imagine that the software exists to do this. Indeed, the process of discussing priorities and weighing them up against the strategy is often something the product visionary needs to have a hand in and that needs to be understood by the team. Pressing a button just won’t cut it.
That said, there are tools that exist that help to generate the finished roadmap based on the goals that you set. I’ll stop short of making recommendations as there are just too many variations but product management discussion forums are often awash with user stories of people using such software.
It’s worth writing a little for those businesses that are in the situation of having an outsourced development team. Not every company can afford their own developers on staff and so it’s common for software projects to be put out to tender or to partner with development agencies.
The main takeaway should be that the guidance in this document still applies under this setup. However, to make it work you - as the commissioning body - need to be transparent and open about where you are going with your product. If anything, always over-communicate messages to the development team.
For the software development team, it provides an invaluable horizon-scan as to where things are headed, what they should be thinking about and in what way they’re going to get there. For them, the worst case scenario is that features are bundled in at the last minute without understanding why. If your software team ever looked surprised then that is a real red-flag to the way you’re doing things.
In this situation a roadmap is often a really good idea. It helps bridge the gap between what the client wants and what the software developer understands. You must trust and work with your developer in order for the roadmap to be a success. Do not think of it as yours - it remains a collaborative document with the software supplier having an integral input into it.
Ask the software developer to sign a non-disclosure agreement, pay a retainer, get them on contract or whatever it takes but make sure you feel comfortable working with them. I can’t stress how important that relationship is for making the roadmap work, and vice versa.
Roadmaps are a good way of putting a longer term context around today’s priorities. It also helps your business to proceed in-step with each other and to plan milestones. However, roadmaps aren’t for everyone and you shouldn’t let the bureaucratic overhead distract you from building a great product.
If you do decide that roadmaps are for you then make sure everyone knows what they can do and what their limitations are. Get buy-in and keep them up to date and use them as a tool to really capture where the product is headed.
For those commissioning software, make sure you use roadmaps as a tool to create a cohesive environment and that it is reflected in good communication.