The most important tool for PM
Roadmap is probably one of the most important tool for a PM, as it could be use as an internal and or external communication tool. It is also an exercice where you cannot hide and have to straight up say no to your stakeholders, as only the most valuable item can be kept for a near future development.
We operate on a four month cycle. Every four months teams gather in the same room to discuss what we want to build next. Though, we are not taking this opportunity to plan for four months ahead but instead as a checkpoint to mitigate dependancies and align on company vision across teams and families (squad | tribe).
In this article, I will try to detail what is a roadmap, who influence our roadmap process and how we build ours.
what is a roadmap
A roadmap is a strategic artefact, a compas for the team, a communication tool for internal stakeholders:
An artefact because it is not built out of thin air, it require continuous discovery with users to know what are the most important pain points. Discussions with customers facing team to understand what are the broken flows. And validation from data perspective to make sure the problem is impactful.
A compas for the team because it will define what opportunity we want to address in the near future. Roadmap stem from company vision and should help the team understand where we want to bring the product on a shorter term.
And finally a communication tool because the roadmap should include what opportunities are considered the most valuable at a present time. Every person in the company can access it and then be aware of what opportunity will be solved. In theory, the roadmap should always be the answer to the most asked Slack question: “are you planning to work on X?” (the second most asked question is “when will this be released” but more on that later).
It is not the case in my current role, but some young start-up make the choice to have a public roadmap, a movement known as #buildinpublic.
who influence our roadmap
Building a roadmap is a team effort, it is an on-going conversation between severals parties. Even though product team have the final power of decision, users and internal stakeholders are an important part of the equation.
- users:
We have two ways of collecting users feedback; based on Theresa Torres “continuous discovery” we organise weekly interview with our users. Every product team does it, and we are lucky enough to have users who are always available for calls or on site visit.
Our second tool of choice is Uservoice. A platform where our users can submit pain point and vote for already published ones. Same as the interview, we review feedback weekly and make sure we follow up most voted feedback with users interview. Once the roadmap is finalised, we will share it with them.
- internal stakeholders (customer success and customer support)
Customer facing teams are the one who know the best what is not working (either missing or the work around users build). Their insights help us get an idea of a problem size, and they highlight the most valuable users we should talk to depending on the problem we want to solve. Their role within our roadmap process is double; submit opportunities at the beginning and proof test our choices at the end.
- product sens
A roadmap cannot be done without product sens, it is our personal compas based on experience and intuition. Because there will always have unknown unknown and we just can not wait to have all the cards in your hands to take a decision, we have to follow your guts and decide what is the bet that will bring the most value to the product and your users. Product sens is something that we develop over time, and I personally believe that it is strongly linked with the passion and enthusiasm we have for the industry our product seat in.
One roadmap 3 milestones
Even though continuous discovery is on-going, we narrow our roadmap process to 3 milestones: value mapping, product council, all hands planning.
- value mapping
Is the process of formally collecting all feedback of our users / stakeholders within one place so we can rank it across a two by two canvas. On the vertical axis the value (most valuable to less valuable) and on the horizontal axis the effort (largest to smallest effort). Once all opportunity are finalised, meaning: detailed, back up with data, tie to an OKR and ranked on the canvas we moved to the value mapping session with Product council.
- product council
A group of internal stakeholders representing each company team (sales, customer success, support, marketing, etc.). To remain partial, members change every cycle. They are the voice of their own team, and are here to make sure we are not under or over looking any opportunity. The most important question we ask them: “if your team asked you to fight to death for one opportunity which one should it be?”.
As mentioned earlier, our internal stakeholders voices weight in our roadmap process and we make sure they have a platform to voice their questions, feedback, concerns.
Once the product council has spoken, all trio (PM, Design, Tech lead) regroup in Prague for the All Hand Planning event.
- all hands planning
Hospitality is the business of hosting, so it is important for the company to bring people together under one roof. In this case, All hands planning is as much a social event than a business one. We are not only discussing dependancies but also creating the necessary bond to do our job. During an intense day, each product team will have the opportunity to present its roadmap and cross-pollinate with other team (meaning: making sure there are no blockers etc.).
- Roadmap north star
Our roadmap has two core value: we always building an outcome based roadmap and we are not giving specific release date.
It is important to mention that we are always building an outcome based roadmap over an output one. We are not gathering a list of feature request but instead a list of opportunities and problems to solve. Opportunities that will help us reach our vision: delivering a remarkable guest experience. We are not interested in shipping features, our end goal is to change user behaviour. Hence, we are not measuring success by feature adoption but with how much positive impact we made on our users (or hotel guests).
And we are not giving specific date because our roadmap is not a project release plan. Even though we are pressed to comite to a specific date, we are moving away from it and stick to a now, next, later plan. Our roadmap is built at a present time but this time is not set in stone. Hence we allow ourselves to shift opportunities around based on new insight discovered. We should be agile enough to reprioritise if a more important opportunity appear, or just pivot to avoid sunk cost fallacy.
conclusion
Building a roadmap is an exercice that every PM has to go through. It is a team effort where the voice of users and internal stakeholder are important. And when finalised, it should be widely used to get all parties excited on what comes next.
