Deciding to go for low-hanging high impact features is the obvious choice, and it's not the choice that makes developing product roadmaps complex. The trouble i

Deciding to go for low-hanging high impact features is the obvious choice, and it's not the choice that makes developing product roadmaps complex. The trouble is always around technical debt. Every company has technical debt. Stuff that: a) Is architectural. Changing it impacts code all over. Think "preparing a database schema for sharding". b) Is a looming ceiling on growth. c) Is not in the immediate present nor is in the far too distant future. When to tackle these is the usual war in my product roadmap meetings. My default rule is the classical 80/20. 80% of the time reserved for new features, 20% for technical debt. If no technical debt is evident, use the time for load testing and optimization.