How To Make Your Roadmap Great Again And Execute It Efficiently
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 my story will give you some ingredients that will help you in your situation.
Product roadmap is often source of friction internally & externally with customers and partners. It is sometimes even seen as counterproductive.
Main reason is that most of the product roadmaps have not evolved as fast as product management and engineering practices since the 90’s.
Look for “product roadmap” in Google images for example:
Most of product roadmaps are a list of features on a timeline, it’s sad.
Looks like the good old Gantt chart friend isn’t it? The one our elders were using in the 90’s to deliver project using V-model development process. Yes, the one that pushed 17 frustrated engineers to create the Agile Manisfesto in 2001 which lays down the foundation of Scrum, Kanban etc. methodologies.
To build this type of roadmap, you only deal with these constraints:
First, everybody knows that being on time with the planned cost, scope & quality is unrealistic and quality is often the only adjustment dimension.
In 2011, the Harvard Business Review examined 1,471 IT projects, comparing their budgets and estimated performance benefits with the actual costs and results. They found that the average IT project overran its budget by 27%. Moreover, at least one in six IT projects turns into a “black swan” with a cost overrun of 200% and a schedule overrun of 70%. In other words, while a lot IT projects will fall short of their budget targets, a few might overshoot the targets so much as to cause catastrophic organization-wide problems (source)
Second, these constraints are often used also as success criteria. However, when you ask somebody about a product he loves, does he answer by saying “I love it because it was deliver on time”. No. Never.
Success definition is specific and must be defined by Objective to reach.
I’m not saying that cost, time and scope dimensions have to be forgotten, they will always remain important. I’m saying that a product is not a succession of project to deliver. Other dimensions such as the technical and functional quality including UX of the output, the end-users outcome (what they can do now that will drive business impact?) and the business impact for the stakeholders and the company (less churn etc.) are also important.
These last dimensions are even more important in product management compare to project management.
Here is a more comprehensive view of product constraints and success dimensions on what I called the product management triangle:
These kind of roadmap are deprecated whether for product or project.
We need to try to forget this old way of building roadmap in order to imagine a new kind of roadmap that take into account all the dimensions, new product management & engineering practices and internal and external needs.
To find a solution, we need first to deeply understand what are the problems experienced by the internal teams and ultimately by the end-users to try to remove passion from the debate and have a shared understanding of points of view.
Why 90’s Roadmap Sucks And Is Source Of Friction?
The Product Team Point Of View
Product team (including product management and engineering) problems are that 90’s roadmap requires feature delivery dates and it focus on output rather than on end-users outcome and business impact.
However, features delivery date requires estimation and everybody knows in product that giving an estimation is hard and time consuming. Smaller is the thing to estimate, less rough is the estimation. Giving an estimate at a roadmap level of granularity which is high (like “Release of new version of the app”) is giving a ballpark estimate because product team doesn’t know exactly what will be delivered. Also, it assumes the feature is going to deliver end-users outcome & business impact however nobody knows!
And product team is asked to be accountable for these dates, unfair isn’t it?
To illustrate with some figures, we see that “unrealistic expectations” and “estimation” are the 2 main causes of software delivery problems:
Also, a research paper has been released in 2017 to identify and describe different types of waste in software development, here is the abstract:
Since software development is a complex socio-technical activity that involves coordinating different disciplines & skill sets, it provides ample opportunities for waste to emerge. Waste is any activity that produces no value for end-users
And guess what?
The 1st of 9 types of waste is building the wrong feature or product.
Not convinced yet? You want to continue to lie to yourself by trying to fight uncertainty by asking for features delivery dates and pray for them to work? Let’s dig into it, you will see that value-cost ratio is always negative.
#1. It requires lot of time (talks, docs etc.), the result will always remain an estimate and the time consumed to try to give the estimate could have been used to begin the development which is more efficient to give visibility to the engineering teams and let it tackle risky things first & raise alert if needed.
#2. Ironically, you put energy in writing long docs to get an estimate but the more the doc is long the fewer is the understanding because nobody wants to read a doc of dozen of pages (shared document ≠ shared understanding).
#3. You freeze the solution. However, everybody knows in product that plan to be wrong the 1st time is more safe than plan to be right. You should remain flexible. Even better in an ever changing market. You should celebrate if the solution is different than the one you envisioned the 1st time. It means you made errors, you learned, you enhanced the solution thanks to end-users.
#4. Features’ deadlines are often synonymous of rush, stress, tech debt, ship it and forget syndrome, mismatch between what user needs and what has been shipped and ultimately engineers’ turnover.
#5. At the end, best case scenario is that you come up with a solution on-time with a high risk having a gap between what you envisioned and what end-users actually need (which can be lot different compare to what they expressed). Worst case scenario, which is sadly the most frequent one, is that you come up with a delayed solution matching approximately end-users need.
#6. There are a lot of jokes about giving estimation
New engineer: “How do you estimate how long a project will take?”
Seasoned engineer: “I sum each task time, then multiply the sum by pi.”
New engineer: “Why pi?”
Seasoned engineer: “It ensures that all my budgets are irrational.”
By Mark W. Lund (who has a PhD)
Ok, I admit, #6 is not relevant but quite funny.
The Customer Success, Sales... Teams Point Of View
On the other hand, customer success, support teams etc. can’t discover during demo, training or business review new feature or that a workflow changed. They are in touch every day with end-users, it makes them lose credibility and trust whereas it’s key for the relationship. Also, your company will look disorganized, without process, like a very early stage startup.
They have to be able to show end-users what they can do now, answer their questions at day 1 to ensure they are on-boarded & satisfied by testing new features before them and have their feedback taking into account.
Sales teams, generally through marketing team often have to adapt marketing materials (pitch, core deck, demo scenario etc.) and train sales executives to the new features. Their job is also to make new features shine, make people talk about it, be sure that everyone on the market knows about the new crazy stuff the product team has built.
When Microsoft asked their users what they wanted added to Office, they found 90% of the requested features were already there. They had just done a bad job of onboarding (source Intercom on Onboarding e-book)
Finally, what’s the point of shipping a feature for shipping a feature and forget about it? Everyone should know in a product-led company that most of the work starts after the release. Do we reach the end-users outcome wanted? Why not? What metrics & end-users are saying? Etc. If nobody heard about what problem it solves, what they can do now etc. shipping a feature is useless because nobody will use it and nobody wants that.
These teams need visibility & commitment to organize themselves as they run the business with marketing programs, analyst & partner relationship, quarterly business reviews etc... that rely on dates and deliverables.
And product team should be willing to provide visibility and commitment as they want what they built be communicated, promoted widely, used to collect precious feedback about what/why they should enhance.
Do you release without having quality assurance done? No. Do you release without having given visibility and having other teams on-boarded? No.
That’s a no-brainer question.
Like in a series circuit, if this step is missing, light doesn’t turn on at the end.
Also, there is a difference of culture to have in mind. Sales team especially are used to be commitment driven. They use objective like “sign $X of new MRR by end of Q1” for years & don’t understand why other team can’t do the same.
In a nutshell, customer success, sales, marketing, support teams etc. are keys for the go-to-market of what product team builds. Each team needs the other to be successful, that’s why they should be best friends.
The Cherries On The Cake For All The Teams
Often roadmap is done by only few persons in the company (the VPs for ex.) without any open consultation. Other people must follow and often suffer. Nobody is committed to the roadmap, the document is used one time for a presentation, is forgotten and become useless because obsolete.
Also, a very bad side effect of 90’s roadmap is when teams begin to sell the future instead of the present. They create commitment with customers and partners for a feature at a specific date with a specific scope and often the feature is late even before development started. This can kill your company.
What should be a roadmap after all?
A roadmap should help to align, commit, coordinate all stakeholders and communicate internally & externally the strategy to get the product closer to its vision.
The proposed solution is organized around 2 inherent pillars: the creation of alignment and commitment by open-sourcing the roadmap creation process to give autonomy and trust to the squad by scheduling Objectives to reach instead of features to deliver and measuring success with Key Results.
Open-Source The Roadmap Creation Process
Alignment & commitment begin with collaboration. Goal is to give a chance to stakeholders to express customers problems, hypothesis 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 give their feedback about what their main problems are 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.
Example of Google Chrome product vision:
Be a fast, simple & secure browser for everyone to experience the modern web.
- A product manager to lead the process. He/she will be the driver of the consultation and the person that concludes at the end.
Step 1: draft problems and hypothesis to enhance the product
This is you as product manager that should have the best comprehensive view of problems and hypothesis to test to solve them as it’s your job to know the market, where the company wants to go, to talk regularly with (prospective) customers & internal teams. You can draft it by using a template to present a list of problem oriented hypothesis to have a quick overview.
Each problem must be linked to the product vision to remain focus.
Grouping hypothesis by problem helps to always remain focus on why we want to test theses hypothesis instead of hypothesis by themselves.
Talking about hypothesis helps to remain humble and adopt a data-driven iterative & incremental approach to reach the outcome wanted.
- 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.)
- Initial hypothesis ; What can we do to solve the problem? (summary etc.)
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.
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 so they know a bit about problems and they often come up with creative & relevant hypothesis to test.
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 overall process in order they can prepare themselves.
Step 4: do a 1:1 with stakeholders
Present your problems and hypothesis 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 also 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, you should have all the stakeholders aligned and committed to the prioritized list of problems to solve.
Schedule Objectives To Reach Instead Of Features
Goal is to focus on end-users outcome & business impact by defining Objectives to reach instead of features to deliver and give autonomy and trust to the squad to achieve them by testing hypothesis.
I propose here to use a well known and cool 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.
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 their failed and learning etc.
I wrote this story if you want to know more about OKR.
Let’s continue, begin by taking the 3 most important problems to solve.
At this step, your squad must have a good overview of problems & hypothesis.
Do a workshop about objectives your squad can define for themselves that could be reached at the end of this quarter to solve these problems.
Objectives must be designed to get your squad jumping out of bed in the morning with excitement. They must be specific, hard & inspirational.
Limit your squad to 3 Objectives max to remain focus.
No need for estimate! As your squad has an overview of hypothesis to test to reach the Objective(s), gut feeling of the squad is reliable to know if as a squad you define 1, 2 or 3 objectives to reach 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.
Then, define with your squad what Key Results you will use to know if you are making progress and have reached Objectives or not at the end of the quarter.
Key Results represent the end-users outcome the squad absolutely wants to reach thanks to the hypothesis to test. They 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, save time and not have a too painful process.
At the end of each quarter, after assessing current quarter OKR and sharing the assessment, review with stakeholders if Objectives defined and problems linked are still the ones to achieve to define next quarter Key Results.
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 your squad is getting closer to the product vision.
Output example (template source)
Remember that everybody want to dream about what’s coming.
Despite everything, sometimes, date happens
Two 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 hypothesis minimum solution in EPIC / 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 or weeks 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, users needs not matched etc.).
About Execution, Communication And On-Boarding
Here we go! Once the squad agrees about OKR, it can start to execute. Remember, you have defined the destination with Key Results (KR), not the road to reach them. You should pivot when needed as you learn by adapting initial hypothesis and testing new ones to reach KR defined.
Execution engine should be composed of two continuous inherent parallel tracks: discovery & delivery.
Concerning discovery methodologies (Design thinking with design sprint etc.) and delivery methodologies (Scrum, Kanban etc. with the help of complementary methodologies like story mapping), start by using the one that best fit your team by the book and adapt it as you learn.
Keep in mind that the real purpose of the methodology is not the methodology. It is to help you to reach KR defined, deliver end-users outcome and business impact by being empathic with end-users and by doing high pace iterative and incremental discovery and delivery.
Start the discovery with your squad and optional guests for your 1st objective to reach. Remind them the Objective story (mainly problem you’re trying to solve thanks to this Objective, Key Results to reach and initial hypothesis). Then ideate on hypothesis and what you think are minimum solutions by hypothesis. Try to find the golden mean between the number of hypothesis and minimum solutions by hypothesis you want to prototype.
Then, test & iterate with beta testers with a strong focus on risky parts. Do your best to prototype hypothesis without a single piece of code by doing low-fidelity mock, animated user flows etc. Goal here is to fake it in order to know if it’s worth building. If it works, this means that everything the squad works on after will help you to progress… No waste!
Every product manager’s goal is to minimize output and maximize end-users outcome & biz impact, Jeff Patton
You can start the delivery once you’ve found hypothesis minimum solution that are worth building. Remind your squad and quality assurance tester about the hypothesis (mainly problem we are trying to solve again, OKR linked, solution prototype and key learning from discovery) and continue with a talk & doc session to break done each hypothesis minimum solution in EPIC / user stories with acceptance criteria and wanted end-users outcome that must be quantitative, measurable etc. (same rules as KR). If you progress on your hypothesis minimum solution end-users outcome, you should progress on your KR also. KR are just an higher level outcome.
Once ready, user stories can enter development pipeline until they’re done.
Then, you activate hypothesis minimum solution only for relevant beta testers and internal teams in order to measure, learn and iterate until viable.
A viable solution is at the intersection of feasible, usable and valuable meaning it reaches its wanted end-users outcome and makes you progress on your KR.
Story mapping methodology is useful to not get lost on the path to iterate until viable by keeping an overview and focus on end-users experience.
A feature flipping solution is required to show an hypothesis minimum solution only to beta testers. It will help you also to do progressive roll out (10%, 20% of your customers etc.) to continuously measure and learn to check if end-users outcome and business impact are still there as customers subset increase and limit risk due to unanticipated side effect for example.
On a technical point of view, Integration and Deployment should be done Continuously (CI/CD) to go live, measure and learn as fast as possible.
If the hypothesis is validated meaning you managed to achieve a viable solution and you want to make it generally available, we can then call it feature or product depending of what you are building.
Concerning internal communication, the squad has the latitude to build what’s best to reach the Key Results defined so it implies frequent communication (every week for example) to other teams in order they know and be prepared on what’s coming on. OKR progress report and delivery rituals like product demo are powerful tools to communicate internally.
External communication should be managed by the product management and product marketing team and split in release. Release process should be defined between product team and other team in order to be effective. Your end-users and internal teams have to follow the pace and you can’t communicate all features with the same guidelines because potential high-impact features will get lost in the noise and lose their impact. You can communicate for example every month new low/medium impact features in a minor release and every quarter high-impact feature in a major release or communicate independently each new things with specific guidelines depending of the importance for example. Just be as much careful with internal teams than with your end-users. Like I said earlier, internal teams have to be able to show end-users what they can do now and answer their questions at day 1 to ensure their on-boarding & satisfaction.
That’s not finished! In fact, it’s the beginning of your feature life. And new features are like your children, you have to support them. As I said earlier, customers on-boarding on what’s new is key in order end-users know that there is a new thing, understand what they can do now and how. You should continuously follow the feature in order to check since general availability if it continues to reach the end-users outcome wanted, if not why and decide the action: new communication, frequency and/or adoption improvement or kill the feature. Killing a feature should remain a possibility, possible causes: usage decline & it is not a priority to enhance, it costs your user & internal teams because it becomes too complicated to use, it’s costly to keep up... Even if you did your best during discovery, it happens, you should remain pragmatic even if you were part of the building team.
You have 2 ways to improve your product: add new or improve features. Don’t get lost in feature adding.
I hope this was useful. Don’t hesitate to share feedback and have fun!
Resources to learn more: