The traditional product roadmap may have finally run it’s course, and I think that’s great news. The reason for this is two-fold. Firstly, the way in which we make traditional product roadmaps often prevent teams from being innovative and successful. Secondly, traditional product roadmaps often tend to include development time chunks and dates – which are often unrealistic, ending up with disgruntled, overworked employees, and in worst case scenarios, even destroying your team.
So you maybe wondering, what is the optimal roadmap? In my eyes, the optimal product roadmap identifies the problems that are driving the company strategy, outlines the vision, the challenges and the targets which all reflect the end goal. The optimal roadmap should be something that the whole team understands and feels a sense of ownership for.
This is a topic that we’ll be coming back to over the next few months, so for now, here’s a brief understanding of what you should do when creating your next product roadmap, and what you shouldn’t do.
The Don’ts
DONT: Play the guessing game
You’ve probably guessed it and your definitely right, Product roadmaps are named after original roadmaps – you know, the things that get you from Destination A to Destination B. And when planning to get from Destination A to Destination B, you always tend to allow more time than you actually need in case there’s traffic, or train delays. So surely it makes sense to apply the same principles in your product roadmap, especially if it involves creating software. In fact, you’re better off keeping your dates on your product roadmap as broad as possible.
Taking the estimated timeframe from your development team as gospel is automatically setting your product up for failure. Don’t get me wrong, i’m not putting down engineer’s whatsoever, they know the technical parts of your product better then you do. It’s just near impossible to estimate the timeframe for software when planning roadmaps so far in advance. If your development team are restricted to a tight time frame then they’ll either rush through the product to get it released in time, which results in little testing and therefore buggy code, or the product doesn’t even make it to it’s final destination.
DONT: Forget to Involve all members of staff
As product leader, the biggest impact you have on product roadmaps is how you organise your teams and define missions. If you hand over a roadmap that your product team have not fully contributed to, they won’t feel like they’re owning the work they’re doing, which will inevitably lead to poorer work ethic and poorer solutions.
Work closely with others in the leadership team, involving members of the teams that are on the front lines with your customers. You don’t have to give everyone a seat at the planning table, but seeking out their knowledge will not only provide you with a higher level of direction and context for planning, but will also help the whole business organise and define missions that work, by encouraging communication.
DONT: Forget the customer
Instead of focusing on features to be developed, you should focus on problems to be solved. What is reason for your product? How does it help the user?
Use the first phase of your product roadmap as an opportunity to discover problems and experiment with solutions, and the second phase on building the product and testing and validating the final results. Keep the features minimal to make sure your teams focus is on solving the problem, and if a product needs to be built out more at the end of the time frame, the further problems and features can then be prioritised.
And the do’s
DO: Make your roadmap visually pleasing
Making a roadmap that is easy on the eyes will not only make it easier to understand but will also allow your meetings to move naturally through the big picture strategics on the roadmap, because everyone in the team can see their items in relationship to everything else.
DO: Focus on the big picture
Your product roadmap needs to be high level. It’s a place for the product manager to present their visions, plans and updates. In other words, only the strategic essence on your product. Any more detail and your roadmap will create clutter, and clutter creates confusion.
When creating your product roadmap, it’s best to think of it as “designing” rather than writing. There are plenty of places to capture and track individual feature ideas. But where possible, try to minimise their presence on the roadmap.
DO: Tell the story
There are many ways to approach the vision and strategy of the product, but the important thing is to make sure is it exists and are understood. As a product leader, you’re responsible for setting these plans in motion, so it’s important for your team to understand their context within the business.
You need to keep telling the story of the product and showing that what people work on every day is driving towards this goal. After all, Any plans your team create ultimately drive towards the same shared goal.
DO: Change your focus
It’s widely believed that product roadmaps should focus solely on solutions and the FAB – features, advantages and benefits. But this usually results in the product team ignoring what they set out to do in the first place: solve problems. Focusing on the advantages & benefits, speccing out your product with elaborate features lets the original problem become more of a rumour then something to solve.
Product teams using traditional roadmaps generally don’t spend much time analysing if the problem is still relevant because it had been so obvious when they planned the roadmap. And when a team is more focused on meeting deadlines than creating value for a user, that team is in trouble.
DO: Expect that your roadmap will change.
Product roadmaps should reflect your teams latest strategic thinking as of now. Thats because priorities change and so do budgets. Unfortunately, most teams only revisit roadmaps 2-4 times a year which is too infrequent to respond to change fast enough. Reviewing and tweaking the roadmap often will allow for wiggle room when responding to customer feedback.
Developing an excellent product needs extensive research, a great UX, solid development, and plenty of testing. Estimations in roadmaps usually leave out at least two of these: testing and research. When you fill up 100{a990e605127f06bac58d8f530ec8d3ddc1721ced564bd12be3752b381e1e9f7f} of your allotted time in the roadmap with development, you leave no time to act on feedback and make improvements.
Ultimately, how you choose to design your product roadmap is up to you – the product leader, but remember, it’s what ends up in the hands of the user that matters. And finally, don’t forget that your roadmap is a way for you to communicate and align your product team across big picture goals, problems and time horizons – if it can’t serve it’s purpose then it will limit your teams innovation and success.
Newsletter sign up
