Why Feature Timeline Roadmap Sucks? — How Can We Make Roadmap Great Again? — Ep. 3/4
My story’s goal is to share with you some tips I learned as product manager in B2B SaaS software companies about roadmap and its execution. What are the problems I encountered, how I analyzed them and what solution I found to go through. This topic is hard, I think there is no magic recipe however I hope it will give you some ingredients that will help you in your situation. The story is divided into several episodes. I hope you will find it interesting! Happy reading!
Here is episodes’ list if you want to quickly jump on the one you’re interested in:
- Because We No Longer Make Thing Like In The 90’s — Ep. 1/4
- What Are The Problems Of This Kind of Roadmap? — Ep. 2/4
- How Can We Make Roadmap Great Again? — Ep. 3/4
- How Execute This New Kind of Roadmap Efficiently? — Ep. 4/4
A roadmap helps to align, commit, coordinate stakeholders & communicate internally, externally the strategy to get the product closer to its vision.
Roadmap can be seen as a transmission belt in a product-led company
The proposed solution is organized around 2 inherent pillars:
1. The creation of alignment and commitment about the problems to solve (not solution) by open-sourcing the roadmap creation process
2. Give autonomy and trust to the squad by scheduling Objectives to reach instead of features to deliver and measuring success with Key Results
About open-sourcing the roadmap creation
Alignment & commitment begin with collaboration. Goal is to give a chance to stakeholders to express customers problems, potential solution to test and share their feedback. That’s also very powerful to get new ideas.
If you have done this process already several times, you can test the direct integration of strategic customers in it. They will be very happy to talk about their main problems and contribute to the roadmap.
There are a few requirements:
- A product vision to inspire, give direction and remain on track. You have to summarize in one sentence where you want to go with your product. Vision is long term, it should change only every few years. If you have 1 product, company and product vision can be the same otherwise all products visions must support the company vision.
- A product manager to lead the process. He/she will be the driver of the consultation and the person that concludes at the end.
Example of Google Chrome product vision:
Be a fast, simple & secure browser for everyone to experience the modern web.
Step 1: draft problems to solve to enhance the product
This is you as product manager that should have the best comprehensive view of problems to solve as it’s your job to know the market, where the company wants to go, to talk regularly with customers & internal teams.
Each problem must be linked to the product vision to remain focus.
Template example:
- Problem ; Formulate simply the problem you want to solve
- Why? ; Why this problem is important? (data, feedback etc.)
- For who? ; Who are the targeted users? (vertical, personas, etc.)
- Potential solution (optional) ; What can we do to solve the problem?
Potential solution are optional at this step. If you have potential solution in mind, group them by problem to solve to always remain focus on why you want to test these potential solutions.
Talking about potential solution helps to remain humble and adopt a data-driven iterative & incremental approach to know if it helps or not.
Try to not exceed 5 to 8 problems in order to remain focus.
Formalize it in a collaborative doc tool to ease sharing and collaboration.
I talk mainly about problem here but you can also include opportunity.
Step 2: include your squad in the reflexion by doing a workshop
Remember as product manager your squad is one of your stakeholder. They do things, so it’s a must have to be aligned and have them committed.
Also, better they understand the why?, better will be the result of their work (both functionally and technically) and the best way to have a shared understanding about the why? is to discuss about the problems to solve.
Finally, they are the ones who know best the product.
We say if you’re just “using” your engineers to code, you’re only getting about half their value, Marty Cagan
Step 3: begin on-boarding of other stakeholders
Present the roadmap creation process to each stakeholders (e.g. by email) in order they understand why they will be asked to contribute, what they will have to do and the process in order they can prepare themselves.
Step 4: do a 1:1 with stakeholders
Present your problems and potential solution draft and ask for feedback to challenge your outlook. To be more representative, ask them before the meeting to do a review with their team in order they can give you the team points of view about main customers problem to solve. 1:1 format is important in order they can tell you their vision, constraints etc. without any bias due to the presence of other stakeholders.
Step 5: prioritize problems
Thanks to previous steps, you should have a representative list and a good understanding of problems. You should also have developed a strong opinion proofed by data of what are the most important ones to solve. Then, order them by decreasing importance in order to know what problems you want to tackle first. Remember that prioritization by committee doesn’t work, prioritization is not democratic, there will always be unsatisfied persons and that’s fine otherwise no one is satisfied.
Step 6: share the doc with all stakeholders
Ask them to share their feedback in the document in order others can see and react to them. Communicate a deadline and try to create momentum.
Step 7: conclude the consultation
Make sure all comments and conversations are answered and closed to avoid frustration and thank everyone.
At the end of roadmap creation process, you should have all the stakeholders aligned and committed to a prioritized list of problems to solve. Now, it’s time to handing over and trust the squad to solve them.
To frame problem solving, I suggest to use a well known collaborative goal-setting and measurement methodology: Objectives and Key Results (OKR).
In a nutshell, your squad sets 1–3 high-level Objectives to pursue on a quarter, along with 2–3 Key Results (high level end-users outcome) you’ll use to determine whether you’ve reached the Objective or not.
OKR helps companies to execute well by making sure everyone is focus on what really matter, has the big picture, is empowered, on-time, communicates about their progress, shares failed and learning etc.
I wrote this story if you want to know more about OKR.
Begin by taking the 3 most important problems to solve to remain focus.
As your squad has an overview of potential solutions to test to try to solve the problems, gut feeling of the squad is reliable to know if as a squad you try to solve 1, 2 or 3 problems for the quarter. Remember the negative value-cost ratio if you want to have less rough planning… Your squad can be wrong but guess what, it’s OK, faster you fail, faster you learn.
Once you have defined the problems you want to address, each problem will become an objective for the squad.
Objectives must be designed to get your squad jumping out of bed in the morning with excitement. They must be specific, hard & inspirational.
Then, define with your squad what Key Results you will use to know if you are making progress to solve the problem or not.
Key Results must be quantitative, measurable, progress oriented, difficult but not impossible…
Limit your squad to 3 Key Results max by Objective to remain focus.
That’s it, you have your roadmap for the current quarter.
For the 2 next quarters, do the same except you define only Objectives.
Idea is to give visibility on the strategy for the next 9 months without setting in stone now how we will measure achievement to remain flexible as environment often changes, to save time and avoid a too painful process.
At the end of each quarter, after assessing current quarter OKR and sharing the assessment, review with stakeholders if problems are still the ones to solve to define next quarter.
It’s OK to have an Objective that last 2 quarters if it is still relevant.
Quarter time bound is just an important checkpoint to set a high level cadence of introspection to check if you get closer to the product vision.
Despite everything, sometimes, date happens.
2 possibilities here: you have to provide a date or the date is set externally.
If you have to provide a date, take the time to do specific discovery on what has to be delivered on the specific date (more on that later). Once finished, break down tested potential solution in user stories and try to do your best to figure out with your squad how many sprint or weeks it should take to deliver it then add several sprints to have the time to iterate until viable and commit to this date as a team.
If the date is set externally, do the same and present what has been delivered on the date. Don’t rush to try to deliver everything, it will take longer in the end (remember: stress, tech debt etc.)
Create alignment and commitment about the problems to solve to give the squad autonomy and trust to set objectives to reach and measure success with key results. This is what I suggest. Once roadmap created, you need to execute. It’s good timing, it’s the focus of next episode!
