Priority changes, expanding scope and switching work from one project to the other all have a cost. Too much of this and you don’t get anything done: you’re just treading water. It doesn’t matter if you or customers drive your roadmap and it’s changes (though you would want to have a prioritisation framework to decide based on what business metrics you prioritise projects).
The first thing you should do is create stability within an ever changing business environment and also capture the cost of the priority churn. So create a roadmap, and have a process to capture priority changes, and how much WIP work is wasted (=not shipped, as it’s deprioritized) as a result.
There’s a bunch of tools and methodologies you can use for this. Sprints, scrum, OKRs etc.
As an engineering manager in a similarly fast-moving environment, the two main rules I follow are:
1. We don’t do any work that does not have impact defined: what happens or what we expect to happen when this project is shipped. This is usually in some numeric value. And we always work on the best impact/effort project next.
2. The team _always_ finishes what we start and we do small enough work items/milestones that enable us to iterate quickly.
Good luck!