To clarify, let's say you are asked for a feature. The normal workflow is to determine when it will finish and crunch for the deadline. Once the deadline arrives, you are going to finish and release at the same time and hope that you have done enough testing during development. At this point get ready for embarrassment because you will inevitably make a few mistakes and cut some corners.
What I am suggesting is, you take a bunch of requests, but manage two roadmaps. One is the feature roadmap with reasonable dates, the other one is the release roadmap which lags one week for each feature. So once you release that awesome backtesting feature, you've been testing it internally since a week and finding bugs as you go. Do not release when done with a feature.
Ok, I think I understand better now. We typically turn on the feature for internal users first and then do a gradual rollout using feature flags so it's not as high stakes and can be rolled back easily in case of problems.
Yes, feature flags are technical debt and need to be removed after rollout is complete. But undeployed code is debt, too, and the ability to do gradual rollouts or pull features back in case of issues makes feature flags worth it, in my opinion.
What I am suggesting is, you take a bunch of requests, but manage two roadmaps. One is the feature roadmap with reasonable dates, the other one is the release roadmap which lags one week for each feature. So once you release that awesome backtesting feature, you've been testing it internally since a week and finding bugs as you go. Do not release when done with a feature.