A product roadmap is a strategic tool to align everyone in the organization. But a poor one might result in confusion, broken promises, and even conflicts. 3 ways to create 10x better product roadmaps: 1. Focus on goals, not features According to Marty Cagan,
thanks for sharing this, very well summarized. I have not heard of the Cone of uncertainty, can't wait to explore that.
In the first section it is mentioned between the lines that use data to support where possible. When we ask WHY, many PMs use gut or common sense. While it might work, it's not the best practice so always try to backup the plan with data when possible. It will also help.make sure you focus on the right items, that they are measurable and that you make an impact
In my opinion it depends on the goal of the roadmap. But the one you proposed is good to focus on product goals. But for example to communicate to the development team it is better to use more detailed one.
- When teams get a business objective, how certain can we be they come up with good ideas? What if they choose to focus on less important topics? Is it entirely up to them to prioritize, make experiments or there's some top-down guidance (pressure)?
- How can teams provide feedback (to Business) what should also be done? They might have ideas on business priorities, technical debt items to work on, etc.
- How does company culture influence teams empowerment? I saw many companies with a command-and-control culture that the company was willing to change and give more empowerment to teams on the surface, however, their culture was very difficult to change instantly.
This is indeed a fantastic eye opener for PM on the type of questions to be answered before embarking on a product via product discovery.
thanks for sharing this, very well summarized. I have not heard of the Cone of uncertainty, can't wait to explore that.
In the first section it is mentioned between the lines that use data to support where possible. When we ask WHY, many PMs use gut or common sense. While it might work, it's not the best practice so always try to backup the plan with data when possible. It will also help.make sure you focus on the right items, that they are measurable and that you make an impact
In my opinion it depends on the goal of the roadmap. But the one you proposed is good to focus on product goals. But for example to communicate to the development team it is better to use more detailed one.
Great article, thanks for sharing!
Have a few questions, though:
- When teams get a business objective, how certain can we be they come up with good ideas? What if they choose to focus on less important topics? Is it entirely up to them to prioritize, make experiments or there's some top-down guidance (pressure)?
- How can teams provide feedback (to Business) what should also be done? They might have ideas on business priorities, technical debt items to work on, etc.
- How does company culture influence teams empowerment? I saw many companies with a command-and-control culture that the company was willing to change and give more empowerment to teams on the surface, however, their culture was very difficult to change instantly.