MYTH: A product roadmap is a commitment!
When I create a product roadmap, my goal is not to give false hope that all the problems will be solved
If that’s what you were expecting, let’s debunk the myth right now!
To start, a product roadmap is a strategic document that’s supposed to be living and breathing
That means that it gets updated when new insights are gathered
This calibration allows the team to always focus on the most critical problems
The team is then able to plan where they are going and change course in a timely manner
The problem arises when there are unclear expectations of the product roadmap
The most common misconception is that a product roadmap reflects the solution, the time and the investment needed to make it happen
What that is describing is a project plan, NOT a product roadmap!!
And those two documents are vastly different
A product roadmap is not a commitment of what the team will deliver
But rather an articulation of the expected outcome, once the solution is delivered
So, it’s important that I distinguish what is and what isn’t part of a product roadmap from the get-go
Managing expectations to an outcome minimizes confusion and frustration down the road
And my efforts are not derailed
How are you managing expectations with your stakeholders?
Use a product roadmap, to help you plan where you are going, to drive agile
• Have a plan
• Define what success looks like
• What are we focusing on vs not focusing on
• Agile doesn’t mean no planning
• Manage to outcome and not outputs
Shifting from outputs to outcomes
• Test and experiment and try
• Understand the difference b/n output vs an outcome
• What does success look like?
• Focus on the outcome, then design the solution from there
• Iterate until you get to the outcome
How to align the roadmap with agile?
WHY – why are we building the product? Why are you working on this?
WHAT – what outcomes do we hope to drive as a result of the product?
HOW – bridge the gap between high level strategy and what you are building: NOW(2 weeks), NEXT (next 2 months), LATER….Is this really what we should be building?
Disclaimer – this is a strategic communication document, not a commitment…this is a living document
Don’t dictate solutions
How to build a roadmap?
Have some sort of a checkpoint
The team should know the strategy of the product (not the backlog)
Consistently use and reference to keep everyone on the same page
Ideally, everyone can provide inputs, ask questions
o Product manager coordinates with the lead designer, lead developer, executive sponsor and other key stakeholders…essentially everyone who will need to approve it
Common Mistakes to avoid:
Too much detail – 1 to 2 page document. Additional info should go to an appendix
Not clearly defining priorities… Lack of discipline with strategic planning
Focusing on solutions and not on problems…it becomes a project plan
Good Roadmap Qualities:
Having an engaged team…everyone feels like they know what’s going on and what my part is. Even if people are not taking my ideas, I know where it stands
A leadership team that’s focused, know what’s important and know how to feedback that into the documentation
Summary:
Frustration & Friction on teams: sustained friction leads to burnouts
Start to ask questions…why does this product exist? I want to make sure I am aligned…is this right?
Change the mindset
