Scrum Masters do not clear technical roadblocks — you have a technical team and architects for that.
You could benefit from some training and/or coaching before attempting to manage using an Agile process. Nothing in Agile makes a correlation between epics, a roadmap, and due dates. Epics describe the size and scope of an effort. A roadmap is a vision for the product. And Agile avoids due dates – especially dates far into the future. When dealing with ever-changing scope, due dates tied to features are nothing more than arbitrary guesses. That approach ignores the reality that no human can project when they will complete something that has not been defined. Due dates are vestiges of Waterfall, not Agile.
Agile does address projects with ever-changing scope and requirements. I’ll use Scrum as an example: Scrum fundamentally defines a Sprint as a period of time in which the team can deliver some working solution that has value to stakeholders. Many teams use a two-week Sprint, and some use three or four-week Sprints. The team decides on the Sprint duration based on what the stakeholders expect to be delivered AND sufficient requirements. However, the Sprint model’s success depends on a few ground rules; and the most important rule is that scope does not change once the Sprint starts. This is why Sprint durations are short.
The expectations of specific features being delivered by a certain (arbitrary) date become less important once the team is delivering in a regular Sprint cadence. Not many stakeholders will complain if they are getting working valuable features every 2-4 weeks. That is what being Agile is about.
I notice you say you are a Product Owner who is “in charge.” When you put it that way, I get the impression that you may be in a situation where Agile terms are being used, but the practices are not. If that is what is happening, then I hope you have access to a good Scrum Master to help you out until you can get trained.
Read more about managing Agile Teams here.