How I make and deliver a roadmap
As CTO I think planning the product roadmap is one of the most important activities that I do. In a SaaS business I think a well planned and organised roadmap has the potential galvanize the whole business around a common objective in the expectation that it will add more value to your current customers and make it easier to attract new ones. A roadmap delivered on time, that meets your customers’ expectations means that you can expect to see a reduction in churn, an increase in referrals and more leads - ultimately leading to lower CAC (Customer Acquisition Costs) and higher LTV( Life Time Value). In this post I’ll describe the framework that I have developed for my own roadmap planning and delivery - it’s served me well and I hope you’ll find it useful for your own business.
What is a roadmap?
My belief is that a roadmap should describe what you are going to deliver over the next 3 major versions that your product team will work on and to me a major version describes a set of capabilities that are related to a common theme which is designed to address a particular problem. For me a major version could take anything from 6 months to 12 months to deliver in total. Now of course, we not talking waterfall here, but rather taking an agile approach and looking to make small frequent minor releases each of which may seem insignificant but over the course of the 6 - 12 months will culminate in the complete delivery of the theme for that major version.
The roadmap needs to be detailed enough to describe what you are hoping to achieve so that you can discuss it internally, with your board, and with customers and prospects. At the same time - I won’t describe how these capabilities will be delivered - as for one I won’t know and two I like to keep a certain amount of flexibility to keep options open based on what’s feasible.
So in summary, we’re shooting for an 18 month - 2 year plan, that will deliver 2 or 3 themes each of which should address a specific need or solve a problem.
Planning
I think of the roadmap as a living thing and something that can evolve and change over time. Having said that, I think it’s important that the version you are going to be working on next, is well thought out and something that you will commit to. Changing what your development team are going to be working on for the next 6 months at the very last minute creates doubt and in turn leads to a lack of belief from the people you are relying on to either build or sell the thing that you want to build. Therefore, I tend to spend 80% or more just thinking about what our most immediate release is going to be.
There is more flexibility in versions that are further out. Think of them as placeholders, things to socialise and get views on rather than things that are fixed in stone. The further out the release the less defined and committed to delivering it you can be.
I’ve taken many approaches to actually determining what goes into the roadmap, but I always start the process in the same way which is that I will formulate some initial ideas myself. This is a personal preference, but I’m someone who tends to quietly obsess over things for a while and likes to think ideas through before talking to others - I tend to find that I have better ideas in that way. I know that there are plenty of others who get their best ideas from brainstorming sessions in groups. Whatever works is good - but my objective is to come up with some preliminary ideas before discussing the roadmap more widely. I think this serves the purpose of setting the scale on which others can anchor to in later discussions. You will know best how much effort it takes to deliver a piece of work with the resources you have and are therefore best placed to guide how ambitious or conservative a major version should be.
Following this initial line in the sand, I then like to start to gather input from a number of sources. I don’t do this in any specific order - I really see this as a constant process of new ideas, validation, and refinement.
The input I seek comes from a number of sources including:
Customers - I will set up calls with as many customers and sometimes prospects to discuss the challenges that they are facing in the hope that we can identify one or two things that they would like to be able to do with our product but can’t. Sometimes these discussions can be very tactical and be difficult to illicit valuable information from, but a single call with a great customer can make it all worthwhile.
Competitors / Market Research - Sometimes when you’re working on the product it’s very easy to become very introspective and ignore what’s going on in the wider market. Sometimes I will talk to product marketing, but generally I like to do my own research a bit and try and establish what capabilities our closest competitors are offering. I’m not necessarily looking to do a full gap analysis, but having an idea of the various strengths and weaknesses of your offering relative to the competition is a good thing. I will also use market research analysts like Gartner and Forrester where possible. Sometimes this isn’t possible, because your solution doesn’t fall into one of their defined markets, but sometimes it does and their market definitions tend to change more frequently that you might imagine - and in fact I’ve been in a position where the business found itself in the Revenue Intelligence market that had just been defined by Gartner. It’s worth keeping an eye on.
Technology Advancements - For us we started seriously looking at AI back in 2017. Even back then there was a lot of excitement about it and we could see potential of using it to bring insights and recommendations to our customers about their sales processes. I don’t think it’s necessarily a good idea to out looking for a reason to use the latest technology - but I do think that having a technical background and staying up to date with new technologies helps to formulate ideas about how certain capabilities could be delivered that you might have previously dismissed as unfeasible.
Structuring Ideas
Once I have a certain level of input of ideas I start to try and organise them into groups that will eventually become the major versions of the roadmap. To do this I’ve taken 2 approaches. Bottom Up and Top Down.
Bottom Up
In this approach I’ll aim to list out all the ideas and assign scores to each of them based on how valuable they are (based on discussions with customers etc) and how feasible they are to deliver. Having done this I will then attempt to group together ideas that are somewhat related into clusters with the idea that a cluster will define a major version.
Top Down
In this approach I’ll start off with a clear idea of 2 or 3 themes and then attempt to allocate ideas into those themes. This has worked best for me when there are clear gaps that we have wanted to fill, but is also possible to do by considering technology advancements and considering all the ideas that might be addressed by a particular technology like time series analysis.
The bottom up approach makes it very clear what you should prioritise first and it makes the job of sequencing the delivery of capabilities easier. Whereas the the top down approach usually makes it easier to create versions that have greater vision, clarity and punch that you need to sell the roadmap at a later date.
Feasibility and other Factors
It’s worth me pointing out that during this phase I’m constantly re-evaluating how feasible each idea is from two perspectives. Firstly and most obviously I want to make sure that it is something that can be delivered technically and operationally with the resources and financial constraints that we have. Secondly, and this is something that I need to keep on reminding myself, the solution needs to be something that can be sold and marketed by our sales and marketing teams. What may seem like a very small change at a technical level, maybe a huge change for the business and suddenly veering off into a new market with a new ICP is not something I would recommend unless you have no alternative and their is unanimous support for it across the business.
The Proposed Roadmap
I aim to get a roadmap into a presentation that I can discuss internally and maybe get some specific feedback in a few key areas from specific customers. At this stage there should be no big surprises but some tweaks may be necessary before being content with a version that everyone supports. Once past this stage - I wouldn’t necessarily advocate making it available to all, but certainly I wouldn’t object to sales and marketing using it strategically to validate the product-market fit, future demand and to share it with customers who are interested and gave us good feedback in the initial stages.
Pathfinder
Before the development of starts on a new major version. I like to run some R&D on the capabilities that I think are technically the most difficult and risky, either because they require the use of technologies that we haven’t used before or because we don’t know how those capabilities will perform in operational use. I like to think of this as a pathfinder exercise in the sense that it gives us a path to delivering the capabilities when we’re actually doing the development for real as the last thing we want is for the whole program to be delayed or even worse abandoned because we can’t figure out how to actually build parts of the system. It’s best to confront as many of the riskiest parts of the build as early as possible. Usually this is either done by me or one of my senior architects.
Delivery
From the established roadmap we’re into a delivery phase we the task is more about figuring out how we are going to deliver the items specified in the major version of the roadmap. We do this in a fairly conventional way using user stories and discussing as a product team how we can design and sequence the delivery and guesstimating the effort of each capability.
As much as possible I like to have work delivered in 2 week sprints. It’s frequent enough that the changes are manageable from a testing point of view and with infrastructure as code and a decent DevOps pipeline it doesn’t have to be an onerous exercise. Each 2 week sprint is considered a minor version and have it’s own changelog and release notes. That being said we will generally hide features that are still in development behind feature flags which make it possible to release features independently of our changes.
