Dr Rob Phaal and Dr Imoh Ilevbare answer questions on how roadmapping can be used to unify organisations, gain buy-in from senior stakeholders and facilitate innovation in a clear, practical and resource-conscious way.

“One of the key benefits of roadmapping is bringing together people who might be working in silos, to discuss and clarify what needs to be created within that organisation,” shares Dr Imoh Ilevbare, Principal Specialist in strategic technology and innovation management (STIM) at IfM Engage, in a recent Product-Technology Roadmapping webinar.

Roadmapping, when led effectively, provides a real opportunity to unify disparate teams and departments with a shared goal and plan. Paving the way for innovation while considering resource requirements, time constraints, and market opportunities.

“What makes roadmapping so flexible is that the underlying architecture or structure is based on some very fundamental questions,” says Dr Rob Phaal, Director of Research, Strategic Technology and Innovation Management at University of Cambridge, “and if you can answer these questions, you have a coherent strategy.”

Dr Imoh Ilevbare and Dr Rob Phaal lead the course Product-Technology Roadmapping – which teaches University of Cambridge’s innovative Fast Start roadmapping method used by organisations worldwide. Here are some questions posed to them in the webinar.

What kind of strategies should we consider for building a strong commitment within the company to roadmap developing? Do you use task manuals for the company before, during, or after roadmapping?

Dr Imoh Ilevbare: When we create roadmaps, one of the most important stakeholders that we need to get clarity on very early on is who is going to own the roadmap. Because whoever owns the roadmap will drive the roadmap's eventual application.

So, clarity on that, and then of course, having commitment, either from senior management or whoever the sponsor is, is also critical, because with senior management support, it's more likely that people who are required for the process will carve out time to be part of the implementation effort.

Regarding task manuals, it’s important to be clear on who’s going to take things forward. In the most effective roadmapping work I've done, usually you end with who's going to do what. Who's going to take things forward. Who's going to clarify knowledge gaps, and so on.

So clear communication channels are really crucial. We have colleagues who have added some modules to our roadmapping work which involve stakeholder identification and management. Not just the why, what, how, but also the who.

If you need to collaborate with people from outside your organisation, how do you start to engage these people? And how do you make sure that they are helping push your vision forward?

What’s an effective way of securing stakeholder buy-in?

Dr Rob Phaal: In response to perceptions that roadmapping was a heavy-duty technique designed for large corporations, was how quickly can you take the first step?

We found that that makes it more accessible for smaller companies, but big companies also don't want to commit to a large process without being clear about the outcomes. We call these workshop methods Fast Start.

We spent a lot of time working out how quickly can you turn the handle and get a useful result. Quite often, that first step needs to be designed to solve problems that are prominent in people's minds at the time, although there may be longer-term goals as well.

That first step has to generate direct business benefit to the company, and also to everyone involved. We make sure that these workshops are stimulating and engaging for participants, and we get feedback from everyone. Because if people enjoy that first step and find it useful, they'll be prepared to take the second step.

So that's a key thing for getting buy-in. It’s that you're not asking a lot without people being clear of what they can get in return.

How can tech guys push for initiatives that business guys may not be able to see? And any practical tips on how to engage business leaders in technology roadmapping? Typically, I experience massive oversimplification of solutions which results in lack of understanding of technology development resource and time needs.

Dr Imoh Ilevbare: In terms of technological solutions and the level of sophistication required to develop and apply those solutions, those are some of the things that we think through in the third roadmapping workshop.

First of all, you need to point to the features you need to develop and then try to break down how you're going to develop them according to technology solutions.

You could also link back to how these technology solutions address the product features, and how those product features meet market needs and demands. So that communication or that understanding becomes clearer, the tech people are more able to communicate to the commercially minded people.

Other things that you could do as part of the analysis is show the interconnectedness between the different technology solutions, because usually one technology solution might affect another one, or how you implement it.

In the fourth workshop, where you do the charting, and where we start specifying how many people you need, or how much time is it going to take.

So, for example, if the commercial people want the solution in three months, but with the resources you have, you won't be able to deliver it for the next six months, it becomes clear on the roadmap.

You have the ammunition to ask, “OK, if you really want this thing in three months, I need more people. Or if I’m going to be working with the resources I have, we have to find a way to make it possible to deliver this in six months.”

Product life cycles become shorter and shorter, putting more pressure downstream. How do you address the function time in your process? How will you control resources to balance this NPI-NPD cycle with your process in mind?

Dr Rob Phaal: I think it follows on from what I was saying earlier about making sure that the cycle time is as quick as possible, and there’s no bloat in the system, because if your strategy cycle time is quick enough, you can address all the issues faster than the actual process is playing out.

Now, in software, which is the fastest-moving technology, agile methods are very common, because you just can't wait months and years for one strategy cycle. It's got to be done in hours and days. And so that's a key thing, even in hardware, where roadmapping has its origins. You don't want the strategy cycle to be slow.

Now, the stages in which resources are allocated in your innovations has its own timeframe. But at least you can consider that from a viewpoint which isn't slower than the systems you're working on. That’s everything really. Agile approaches, quick cycles. You can always scale it up as required but the challenge is scaling it down.

You can learn more about Dr Rob Phaal and Dr Imoh Ilevbare’s Fast Start roadmapping techniques in our Product-Technology Roadmapping course.

Watch the full webinar: