As we’ve described in the past, a roadmap presentation is more than just words on a page or screen or whiteboard. It’s an alignment exercise meant to affirm your stakeholders’ motivations and receive nods of approval before moving forward with your plans.
Acing a roadmap presentation requires a whole lot of planning and preparation, because pushback is plentiful and getting people to reach a consensus on a single plan is challenging (it’s why we wrote an entire guide to help). But presenting a technology roadmap in particular has its own unique subset of problems that aren’t common when presenting other types of roadmaps. After all, it is the document that encompasses ALL the technical and infrastructure-related efforts that impact the functioning of an organization.
Here are a few common challenges you’ll experience during a technology roadmap presentation, as well as methods for mitigating these obstacles.
Let our free guide help you build the right technology roadmap for your team. Download it here.
Challenge 1: Translating technical language
Building a technology roadmap means your roadmap is going to have, well, technical stuff on it. And unfortunately, not all your stakeholders are the tech-savviest people around. Receiving questions around “that doo-dad” and “thingamajiggy” from non-technical individuals should be expected.
Not everyone will comprehend every technology initiative on the roadmap—or its effects—as deeply as you. This means during your technology roadmap presentation, you should be cognizant of the language being used.
Sure, if you’re speaking to super technical stakeholders, put that tech talk on full blast!
But if not, reel in the technical talk before you lose your audience and feel like any adult talking in the Charlie Brown world. If you’ve lost your audience, you can say good riddance to any stakeholder-wide approval.
Ready to start roadmapping? Get started with our tech roadmap template and make it your own.
Solution:
The solution to this is not to ‘dumb things down’ per se. The solution is to communicate relevant value and end-goals to your audience; ensure your presentation speaks to the things that your non-technical audiences want to hear.
Each type of stakeholder wants to see something different. Your customer success team wants to know what the customer gets out of upgrading the deployment infrastructure. Sales is concerned with how this upgrade will impact the timeline of delivering a specific feature.
So rather than presenting your technology roadmap’s super-technical view that you show to developers and DevOps (who are interested in the nitty-gritty), present a technology roadmap that has higher-level descriptions and lumps the more technical stuff into more digestible chunks. This way you can say to non-technical stakeholders, “We’re improving infrastructure phase 1,” and give an overview of how it impacts their work, versus saying, “We’re upgrading our JavaScript library from Knockout JS to React,” and (likely) being met with blank stares.
Challenge 2: Forgetting the ‘background’ tasks
A technology roadmap documents both the obvious and not-so-obvious technology initiatives in an organization. So another common challenge that arises with your technology roadmap presentation is that a lot of the not-so-obvious, but equally important, initiatives get lower priority in favor of ‘flashier’ tech projects. That is to say, stakeholders are drawn to more prominent—and relevant to them—items on your technology roadmap versus the very, very essential tasks that are worked on in the background.
Take security for example. A crapload of work goes into maintaining security protocols and keeping data safe. You could allot a big chunk of your technology roadmap just to implementing new security tools. However, during your technology roadmap presentation, stakeholders may be more concerned with why implementing new servers is taking so much time, rather than security-related tasks that are just as vital, but not as in-your-face on the roadmap.
This leaves room for less discussion about these ‘background’ tech tasks and more opportunity for intense questioning when these background tasks do appear on stakeholders’ radars at later technology roadmap presentations.
Solution:
Dedicate time to presenting these ‘background’ tasks. Rather than waiting for your stakeholders to notice it and bring it up, you should call attention to the parts of the roadmap that you want addressed. As the keeper and researcher of your technology roadmap, you included those ‘background’ items on the roadmap for a reason and you want the sign-off. Carving out time to discuss these items during your technology roadmap presentation lets you proactively achieve affirmation from your stakeholders.
Challenge 3: Guesstimating based on unknowns
The unknowns when it comes to technology pile up quickly. Will this new technology integrate with our current system properly? Will it meet expectations and standards that the vendor promised us? How long will it take to get up and running? How many resources do we need to research and implement this new technology? And so on.
With so many questions you can only answer once you start working with the technology, creating a technology roadmap can sometimes feel like shooting in the dark. The lack of information results in making wild guesses about timelines and deadlines that you include on the technology roadmap. It’s a lot of trial and error.
As a result, this opens your technology roadmap presentations to a lot of scrutiny—especially if in the past you’ve been wrong about timelines. And the last thing you want is your stakeholders not confident in the timelines and plan you’re presenting.
Solution:
Maintain that your technology roadmap is a statement of intent. We believe that all roadmaps should be considered—and presented—as statements of intent.
A technology roadmap is a plan that can and 100% will change. If you stress this point and align everyone on this definition before and during your technology roadmap presentation, your stakeholders can’t hold you to every single detail being presented. This definition manages their expectations and eases any tension that may come with changing deadlines or wonky timelines. Your stakeholders will understand the roadmap is a plan and not the be all, end all.
Challenge 4: Technology initiatives are unpredictable
This challenge ties into the previous one. The reason why many individuals will find themselves making crazy guesses about how long the items on their technology roadmap will take is because truthfully, introducing and integrating new technologies is unpredictable. It’s not as simple as downloading and installing an app on to your desktop. It’s a matter of shifting an entire infrastructure and making sure it doesn’t crash your servers. And the bigger the org is, the more complex the procedure gets.
This means the length of some projects on your technology roadmap are hard to gauge—and might just take way longer than anticipated. That also means a lot of stakeholders asking: “Why is this taking so long?” “Why can’t we get it done by x date?” “What’s stopping us from completing this quicker?” These may be familiar questions when presenting any roadmap, but with a technology roadmap it’s especially challenging feedback because you can’t compromise the quality of big tech projects to meet arbitrary deadlines and expectations.
Solution:
If the challenge is that you can’t predict how long the task will take, then just break it up. Literally split tasks into phases and put them on your roadmap as such. That way during your technology roadmap presentation you can present bigger tasks in smaller blocks and be more confident in the amount of time you’ve allotted to each block.
It’s like reading a post and seeing a giant wall of text. It’s overwhelming and makes you think I don’t know how long this is going to take me. Breaking the text up makes it seem more manageable to conquer—even though it’s the same word count. Apply that same idea to your roadmap and you—and your stakeholders—can feel more confident about the timelines you’re presenting, since it’s much easier to manage shorter bursts of time, rather than a seemingly drawn-out project.
Challenge 5: People don’t like change
Okay, this is a universal challenge that extends beyond tech, but it’s particularly significant for technology roadmaps. Users hate when their favorite tech or app suddenly is turned on its head. (Remember all the Facebook re-designs?) And you can expect the same behavior during a technology roadmap presentation.
When change doesn’t sit well with a stakeholder, you might hear something along the lines of, “Things aren’t broken! Why the change?” And frankly, it’s a legitimate fear. There’s always risk when introducing new technology, especially as we’ve previously pointed out that technology comes with plenty of unknowns. So while discomfort to change can be founded, it unfortunately makes it harder to get your technology roadmap approved.
Solution:
Honestly, we’re going to repeat ourselves here—with a twist. Break your key technology initiatives up, but also over-communicate why you’re introducing this new initiative AND why you’re breaking it up. Explain that you want to mitigate the project’s risks and by splitting it into major phases, you can then better monitor and tackle any emerging issues. This approach offers a compromise to any change-resisting stakeholders and assures them that you’re considering the potential liabilities at hand.
Create + share beautiful roadmaps: test drive Roadmunk with a free 14 day trial by signing up here.