In software development, you’ll often hear the term “roadmap” thrown about. If discussed carelessly, it could appear as though there is only one roadmap, the one that drives the design and development of a product. But don’t forget to weigh your product roadmap against a technical roadmap; it’s an analysis that can keep you and your team from wasting valuable resources both short and long term.
Defining a Product Roadmap
The design and development roadmap considers features from the end user’s perspective. For example, such a roadmap for, say, a smartphone would focus on features like:
- Mobile phone technologies (3G, 4G, 4G LTE, and 5G)
- UI gesture support
- Security capabilities, such as biometric recognition (face and fingerprints), encryption and hashing support
This type of roadmap is the product (or feature) roadmap. To quote ProductPlan:
A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. A product roadmap communicates the why and what behind what you’re building. It’s a guiding strategic document as well as a plan for executing the strategy.
They cite five goals of a product roadmap, which are:
- Describe the vision and strategy
- Provide a guiding document for executing the strategy
- Get internal stakeholders in alignment
- Facilitate discussion of options and scenario planning
- Help communicate to external stakeholders, including customers
Defining a Technical Roadmap
While product roadmaps are essential, they’re quite broad in scope. They describe what features are going to be implemented. However, they don’t define how those features are going to be implemented. That’s the task of the technical roadmap; Wikipedia describes the technical roadmap as:
…a flexible planning technique to support strategic and long-range planning by matching short-term and long-term goals with specific technology solutions.
The technical roadmap helps to ground the product map’s vision with how those features will be implemented. In doing so, it shows what is possible.
Continuing with the smartphone example from before, these could include:
- Researching and costing the hardware requirements to support all those formats
- The software changes required to add support for the new formats
- The security implications of supporting the new formats
- Any software and hardware optimizations required to support so many formats
Comparing the Two
You can think of the product and technical roadmaps as complementary, as two sides of the same coin. The features in the technical roadmap feed the creation of features in the product roadmap and are ultimately responsible for determining when said features can be released — if at all.
So, while both roadmaps are not mutually exclusive, features in the product roadmap need to be appropriately prioritized against the features in the technical roadmap. The question is, how do you do that?
There is a range of opinions and strategies. However, one of the best I’ve come across is from Richard Banfield. He states that it should be done through the lens of three key criteria; these are:
- Desirability is the customer-experience focused part of the analysis. This takes into consideration the needs of the end user, the interaction elements, affordances, and how these are to be marketed or sold.
- Feasibility is a technical consideration and will need the inputs of the technical team members. Product leaders are not looking for personal opinions here, rather just what is technically possible versus impossible or highly improbable.
- Viability of the work needs to be considered as a function of the overall business. Viability also includes factors related to the industry, regulatory environment, and financial oversight or legal considerations.
I could talk at length about how to evaluate and balance these criteria, but let’s keep this simple. Consider these three factors as three axes of a triangle, as in the graphic below.
The three factors can be complementary or exclusive. Here’s a hypothetical example of what I mean. Let’s say that you’re a smartphone manufacturer and your product roadmap lists a download speed of 100 Gbps. How does that feature stack up when assessed against the three factors?
Desirability
No other smartphone on the market has download speeds approaching this level. The best on the market are the Galaxy S9 at 71.9 Mbps and the iPhone X at 48.8 Mbps.
So, by being able to transfer data significantly faster (assuming ideal conditions), users could:
- Use all of the latest music and video streaming services.
- Use very high bandwidth specialist services, such as deep sea mining and medical surgery and research.
- Use virtual and augmented reality applications.
What’s more, as this speed is significantly higher than the current market leaders, it opens up the possibilities for many new opportunities. As a result, this feature is deemed to be extremely desirable.
Feasibility
The feasibility of this feature, however, is almost zero. The reason why this feature doesn’t exist in any other smartphone maker is that it’s a speed significantly higher than the current 4G network supports, which is a maximum download speed of 100 Mbps.
What’s more, it’s also significantly faster than the upcoming 5G standard, which supports a maximum download speed between 1 and 10Gbps (theoretical). Here’s a little bit more background about 5G, according to 5g.co.uk:
We probably won’t see any commercial 5G services before at least 2020, so it’s impossible to say definitively what speeds will be reachable.
The 5G standard has been in development for some time and is only just on the consumer horizon. As a result, the feasibility of implementing this feature isn’t technically practical.
In addition, the hardware likely won’t exist for some time, and the software to manage the hardware for the 5G standard hasn’t been widely used by consumers yet. So, for these reasons, this feature isn’t feasible.
Viability
As the feature relates to mobile standards, the viability is also close to zero. The reason for this is that discussions and deliberations about decisions on mobile phone spectrum ranges are notorious for taking years at minimum.
Given that, even if the hardware is on the horizon and prototypes can be made, there will be a significant lag time before:
- International agreement on the next mobile technology spectrum is resolved.
- Consumers have made sufficient use of 5G.
Given the significant speed improvement of what could be called 6G over 5G and the considerable improvements that it offers, regarding speed, it’s far too early to know if there’s a practical need that it can solve. Based on that, there’s no clear case for marketing it to consumers, yet.
The verdict
Based on this (rather short) assessment against the three key metrics, it’s clear that implementing this feature isn’t possible at the current time nor practical. As a result, there is no need to prioritize a technical roadmap against this feature.
However, while this may be a blow to one or more stakeholders, it needn’t be a permanent cutoff. By considering the feature against these three factors, sufficient research was conducted and collated. The investment and research may turn out to be very valuable down the road when the 5G standard is in the early stages of maturing. It’s possible at that time that other manufacturers will only begin looking to the future. Consequently, there will be an advantage, as the research can be refreshed, based on recent developments.
Once the assessment shows that the feature is desirable, feasible, and viable, then the technical roadmap features can be created and prioritized to implement this product feature.
The Foundation for Prioritizing a Technical and a Product Roadmap
While there is a range of methodologies and technical tools for managing technical and product roadmaps, these are not the key factors to consider. The key factors to consider are:
- How desirable is the product?
- How feasible is the product?
- How viable is the product?
By assessing a product feature against these three factors, you can get a good feel for whether a feature is worth prioritizing on a technical roadmap, allocating the required resources into its creation, and approximately when it might be able to be completed.
Admittedly, analyzing these three questions is merely the first step along the path, and there are others that follow on from this. But if this step is overlooked, then all future steps are likely counterproductive and risk wasting any resources allocated to them.
| Published on Java Code Geeks with permission by Matthew Setter, partner at our JCG program. See the original article here: Prioritizing a Technical Roadmap Against a Product Roadmap Opinions expressed by Java Code Geeks contributors are their own. |
