All the explanations for the product technology roadmap out there are baffling, ambiguous and don’t accomplish anything. It’s a case where the clinical business terminology and non-example definitions that are usually given make it seem like some obscure impenetrable concept.
Well, I’ll not only explain this product technology roadmap, but I’ll do it in a way that’s, gasp, relatable to actual technology developers. So, what is this roadmap? Well, it’s a simple graph in its most condensed form, and its purpose is actually pretty simple and straightforward. It just needs to be explained in those terms, which everyone truly fails to do.
So, it’s basically a tool to map out the initial design and deployment of a new technology (and defining the needs and demographics it targets), forecasts for implementing further development or refinement in the future, and a long term plan of sustainability once the product is established.
These three are generally divided into phases of that order, and the final phase is the long term. Well, usually. I’ve seen the map made into a more sequential system where the first two phases are repeated on a smaller scale attached to the final phase as a repeat cycle for sustained operation. But hang that, it just gets back into overcomplicating things.
So, what do you do in your roadmap? Well, phase one is the initial mapping of needs to fill, design to apply, and everything leading up to prototypes and release candidates. This of course entails user experience testing, prototyping, all kinds of things. It culminates in an initial launch of the technology in its most primitive marketable form.
Phase two, which you plan before completing phase one, is the further refinement and enhancement of the product to the ideal state. Having seen the initial release be successful, you begin devoting the effort into adding the polish (features, refinement, redesign) to the system, along with taking in user feedback from the first release.
Having ridden on the initial release to support further refinement, and for initial real user feedback, you launch the product you actually reasonably pictured being designed.
Once it is launched, you go into follow up activity, which is maintaining support for the final product, as well as repeating the second process to update and continue to improve the design, factoring in ongoing user input. At this point, it becomes the technology flavor of the standard product management cycle we’ve discussed before, and so it’s unnecessary to include that closed, repeating maintenance cycle in your actual roadmap here.
Your roadmap here is just three large phases, with a long series of smaller steps in each, some in parallel, to building and launching your technology and achieving stability.
Not everyone uses the product technology roadmap model to plan this stuff, in stead making a series of smaller maps for individual aspects. But, this is a good model to use to get a nutshell of what you must address and manage in order to achieve your final goal for the product. It’s been presented as much more complex and confusing by most, but I hope that the look at it I’ve given here clarifies what a simple and useful method it is.
