Why product roadmaps are so important
And some tips to building your own :)
Having some years of experience working with product teams, I’m pretty sure that this multidisciplinary and agile approach is the right one for developing innovative and customer-centric solutions that really make users’ lives easier. However, product development is not about the sum of each individual’s work, but it is all about how those people can work together in a sense of collective work. In that regard, gathering individuals with so different backgrounds (as it is supposed to be in product teams) to work like that might represent a big challenge. We as humans tend to work inside our comfort zone, so it is likely that throughout team’s sprints, developers start coding features which were written in the format of user stories by the Business Analyst and have been previously pointed as hypothesis by the Product Owner through customer research and stakeholder validation. It makes it difficult to know what the team as a whole is doing and have a sense of collective progress, paramount for agile product development. Furthermore, the key point here is that this working flow does not seem much like agile, doesn’t it?
I want to address such topics here and show how product roadmaps can help the team collaboratively gather the pieces of work and have a view of long term desired outcomes that afterwards are going to be broken down into sprints, not the other way round.
Here are five reasons why product roadmaps can help your team’s progress
- Having long term plans help you make adjustments along the way
Have you ever thought that having no long term plans is just like piloting an airplane without instruments? Just like airplane instruments, a good roadmap must tell you if you’ve already reached cruise altitude or if you still need to boost your product’s engagement, for example. To do so, you should compare your current metrics with the ones you’ve previously defined with your team when building the roadmap. Looking at this, your team can refine the features, sprint’s goals, make decisions based on data or, at least, realize sometime in advance that some desired outcome is not going to be achieved, enabling you to activate your plan B. Otherwise your team is just working sprint after sprint with no acknowledgment about the impact of its work on the business.
Successful sprints don’t mean successful products
2. It connects the pieces of work into something bigger
Even though each one’s work is important and meaningful, it is much more motivating to know what your team is going to deliver as a whole. This is where the real meaning of work takes place, instead of just delivering tasks that were assigned to you through your team’s board. The roadmap should be accessible and visible on a daily basis, so everyone can take a look at it everyday and feel the importance of their hard work.
Also, it is paramount to know that features and deliverables are related to a bigger product and company vision. Giving people a desired condition instead of a desired path creates a favorable environment for creativity, innovation and collaboration.
3. Helps setting and clarifying priorities
One of the most important skills for a product team (especially for the Product Manager) is the ability of saying no! Users are going to make requests, stakeholders are going to have opinions and even the CEO of the company may issue some special feature requests, but if you try to satisfy everybody, eventually you won’t do any good for anyone! If your vision where to go is clear, that will make easier for you to refuse requests that are not related to it.
Another point is that the amount of options and paths available to us are almost infinite nowadays, so we tend to question ourselves more than we should about the path we are following and step back when the best thing is to move forward and iterate on results.
Reinforcing this point, some time ago I came across the concept called the Fear of Better Options (FOBO), that explains why we tend to work in such way.
4. It motivates the team to move on to the next step
When you are delivering a feature it is possible that you are facing many technical issues and things do not work as expected. So, if you don’t have a clear vision about what comes next and why it is important, your motivation to work harder to overcome such challenges decreases. Remembering everyday that time is a resource that runs in shortage increases our critical view about problems and why to solve them.
5. It gives visibility to your stakeholders
Have you ever thought about how many meetings you could have avoided if there was a roadmap? As we are working in an agile environment, we are not supposed to give status report to stakeholders, but at the same time I assume your team does not work in a bubble and your product must be part of a bigger company strategy. In that sense, it is essential that your goals are accessible to everyone in your organization as well as your progress towards it. This kind of transparency increases the buy-in you have from senior management even when things don’t go as expected, because the whole strategy that relies on your product can also be adjusted if it is needed. Moreover, it creates a sense of collaboration with everyone involved.
Tips for building your team’s roadmap
- Don’t “validate” the roadmap with your team
The tricky thing here is the word validate. One of the main good things about having a roadmap is the chance for collaboration that this exercise brings. However, there are some Product Managers that believe they own the requirements as well as the outcomes and the team needs just to validade the technical feasibility and the desired deadlines, but an exercise like this does not generate engagement and sense of ownership within team members. The role of a Product Manager is actually a facilitator of the whole process, someone who gives direction and understands a broader context of the company, giving the team a vision of why things should be done. This description of role is also related to the concept of product leadership, as you can see in more detail here.
There are many collaborative techniques to build a roadmap and I’m going to list a few:
The Radical Product prioritization — It is an exercise to relate features and potential outcomes to your product’s vision;
The Go Product Roadmap by Roman Pichler — Doing this exercise, you and your team are going to list expected delivery dates, goals of each deliverable and metrics that are going to be used later on;
The Lean Inception by Paulo Caroli — It is a five day exercise that is going to thoroughly make you and your team think about many aspects of the product, ending up with a MVP Canvas;
2. Leave room for unforeseeable work
The need to fix bugs bugs, receiving requests from Customer Experience, stakeholders and unexpected technical debt is something unavoidable. One good thing to do is understand that you are going to compromise along the way in order to meet those unforeseeable needs and don’t get frustrated about it. It is even better if your roadmap is not so tight regarding your capacity and you can accommodate such pieces of work that will come at some time and still meet your planned deadlines.
Some agile best practices state that you must leave 20% of your sprint capacity to unforeseen work
3. The roadmap must not be a list of features
It is very common that teams just add a list of features in a presentation and call it roadmap. The real thing is that a roadmap must be a conversation with everyone interested in that process, from the team to stakeholders. In order to be a real conversation, it also needs to state about the business outcomes that are expected from the product. It is even better when the team can relate its goals with strategic initiatives of the company, so even the senior management can connect team work with high level goals.
The Go Product Roadmap shown above is a good example about how to input business information on a roadmap.
4. Validate your roadmap with data
No matter how hard you and your team have worked on building the roadmap, things are going to change along the way and so is the roadmap. Whenever you do this exercise, bear in mind that things are not set on stone. Other opportunities might appear and you need to grab them, changing what has been previously planned. As a result of your team’s deliveries, pick up the data available and cross check them with the metrics you’ve defined and, when things don’t go as expected, don’t be afraid to pivotate and try new hypothesis. If your first delivery didn’t achieve the expected outcome, it may be better iterating over it instead of just moving to the next one on your roadmap. It is virtually impossible to know in advance how the market is going to react to a new product or service, but data will be your best friend in order to try to figure it out.
Besides the metrics that are on your roadmap, the Google HEART Framework is another great tool to think about the metrics related to your product.
Traps that are easy to fall into
Even if you do encourage your team to follow this process, do things collaboratively, validade deliveries with good data, think strategically and communicate well with your stakeholders, there will be many traps on your way and you’d be better be aware of them. I’m going to write down some that I’ve already faced myself:
Don’t stick to your roadmap, change it and (over)communicate!
As I said before, your roadmap is not set on stone. Don’t get too attached to the first version of it and be aware that it is going to change. It is important, though, that whenever something changes, be sure that your team equally shares ownership of such changes and your key stakeholders are up to date. Communicating with stakeholders is a huge amount of the Product Manager’s role, so share your ideas with them, ask for help whenever needed, explain why you think things need to change and it is your job to make sure they have a complete understanding about the situation, not theirs.
Think carefully about the reasons why some expectation was not achieved
When we don’t achieve a certain goal it is easy to think that the team’s pace was not fast enough to deliver on time or the real product is not as good as the prototypes were. But in real life, reasons for failure go far beyond that. Market research may have come with conclusion that does not reflect customers’ needs, users may be facing usability issues that nobody has noticed and many other things may be the root cause for unmet goals. In a situation like these, gather your team, be humble and listen to everyone’s opinion, it is very likely you are going to learn and decide a way to move forward.
Your product roadmap is not your company’s strategy
When talking to senior management, it is common that these people put too much expectation over your product, trying to achieve a wide range of goals with a single product. Such goals might be even contradictory and spoil product market fit. Don’t be afraid to tell anyone in the organization about what your product does not do and is not related to its vision (that’s why it is so important to have it clear), so you can even suggest creation of new products if the company has other needs to be met. Candid conversations will be your best tool.
Be aware that your roadmap will be connected to one (or maybe a little bit more) strategic initiatives of your company, but if you try to fulfill them with a single roadmap, chances for you to get lost are high.
Roadmaps are not status report
Roadmaps will never tell sprint’s progress and they are not even supposed to do so. If anyone looking to a roadmap tries to grab pieces of information like these and complains to you, it is his/her mindset that is wrong rather than your roadmap.
If you face a situation like this, try to explain the purpose of this material and step up the level of the conversation to the business outcomes you and your team are seeking.
Don’t forget your roadmap!
Well, so you and your team have spent a lot of time building the roadmap, goals are aligned, everyone is held accountable and motivated to achieve them. That’s great! So after the collaborative sessions of roadmap building, the Product Manager saves it in his/her computer, the team starts working on the features and that’s it, right? NO, absolutely no! It seems obvious, but if we don’t see the roadmap and talk about it on a daily basis, we are going to forget all the precious and hard work we have done to build it, or worse, we will forget about what we are committed to do as a whole and start working as a group of individuals on their on, which is exactly the opposite of how a product team should look.
Whenever you think some of those traps is happening, give a step back and think what you can do to avoid it. Use the tools available to you and change the course of things.
Liked what you’ve just read? Don’t forget to give this story a round of applause :)
