A great roadmap can drive a companies success, a bad one can cause disaster. Here’s what we’ve learned along the way…
History of the product roadmap
I’m not entirely sure there is a documented “history” of the product roadmap but they entered my world slowly; creeping in as a new, hip alternative to the traditional Gantt chart — the friend (or foe) of software development in an era most of us have now left behind.
The technological advancements that led to quicker software delivery through a more agile approach naturally fell awkwardly against waterfall methods of project management. As a result, a new discipline of product management emerged and brought the product roadmap with it.
The power of product roadmaps
At the heart of product management lies communication. Communicating what has been done, what’s in progress and what is to come is a core skill which is difficult to master — especially with so many stakeholders in tow.
A good product roadmap can be a key driver for successful product teams, amazing products and growing businesses. If roadmaps are produced and managed well, they keep customers & internal teams aligned and sell an appealing vision of the future.
Projecting a coherent plan boosts confidence, gets prospects excited about where you are heading, shows customers you really deliver and keeps the team working towards the strategic goals set by the leadership team. These benefits come when roadmaps are handled well of course. When done badly, a roadmap can consume hours of a product team’s time and become the source of much conflict & confusion.
After many years on the road-mapping coal face, it’s time to share a few things we’ve learned. Note that what is successful for one product & business might not be for another. I’ve started a short survey for software product managers to learn more about how roadmaps are used & created. Take a look at my Typeform.
1. A product roadmap is a living document
Never assume that your product roadmap is a fixed document. If you try to set things in stone, you can’t react to new information that has become available. That isn’t to say you should be changing the whole thing everyday though! Our process involves creating broad themes that we want to address often a quarter or two in advance, then we plan the features and detail in shorter term deliveries.
This works really well because we have a direction & focus but it’s never at the expense of being able to react quickly as things change (which they inevitably do).
We use our own product, Receptive, to automate the creation of the various roadmaps we use. As requirements change status, the roadmaps are automatically updated so we never have to worry about documentation becoming out of date. Very handy & saves a lot of manual work!
2. You will probably need more than one
Always think about your audience when presenting a roadmap. Different stakeholders will be interested in different aspects of your plan so account for that so you don’t waste anyone’s time.
We have the following:
A high-level roadmap we share with customers. It includes features in development & what we have planned. This keeps our user base informed of how we are building the product out in the longer term, but also shows what they can expect to be delivered relatively soon.
Theme-based roadmap for leadership. Know what is expected when you are reporting roadmap to the leadership team. Ours is simple, high-level and shows broad themes of work we will deliver in the coming quarters.
Theme-based roadmap for leadership and sales team Sales team also use both roadmaps. This cuts down on lots of “Where is this up?” conversations with the product team and helps them get prospects excited about where we are heading.
Feature-based roadmap for development teams. At a lower level, we automatically feed features that have been set to a status “Developing” into the development team through a JIRA integration: https://www.youtube.com/watch?v=WiOo97CQQfc
When the development team complete a Task, it automatically releases the feature in Receptive, notifies customers, prospects & team members who were following the feature and updates the Release Log.
3. Hard delivery dates are EVIL (run away!)
We have never found that sharing hard delivery dates is a positive experience for either the software vendor or customer. It sets expectations that are near impossible to keep.
There are just too many factors that can change how long an improvement or new piece of functionality takes to develop. That’s why we choose to show “Features in Development” and “Features that are Planned”. It’s more than enough transparency to keep customers confident we have a plan and strategy behind our product.
4. It’s all about the strategy
When you are creating your product roadmap, always start with the strategy. Usually this will involve input from several people so make sure you know who you should talk to.
There are a load of different ways to create a strong product strategy. Themes of work could be directly linked to company KPIs, part of a plan to crack open a new market or a direct reaction to feedback you’ve received from customers….just make sure you have a strategy in place otherwise you can end up building features that don’t really add anything to the company.
5. Good data is the difference between a sh*t roadmap & a great one
Developing a product strategy and the schemes of development work which deliver it, rely on good data being fed into the decision-making process.
We have 3 main inputs - demand from the customer base, our internal teams and the market.
We collect prioritized requirements over time so we are confident the information we are working with is up-to-date and relevant. Prioritized requirements from customers, internal teams and the market are our inputs. At the other side of the process, we segment all the information we receive. For example, we’ll look at top requests from the market, what customer-facing teams need to reduce churn and facilitate upsell and what matters to a biggest customers vs our small. We’ll also look at feedback from free triallers, prospects and churned accounts separately. Those are just a few examples.
Segmenting prioritized data means we don’t fall into the trap of being pulled around by our most vocal customers, a team member with a particularly strong opinion or a sales team member who needs “just one more feature” to close a deal.
Bringing real, actionable demand insights to our product meetings makes them efficient, productive and actually a whole heap of fun. We are always surprised by what we find in the data. Without it, product meetings would quickly decent into a sea of post-it notes and opinion.
Having Product Demand Intelligence allows us not only to make data-driven product decisions, but to practice truly demand-driven product design.
Happy roadmapping folks!
Receptive brings Product Demand Intelligence to software companies.