Speaking as someone who has been both CTO and Head of Product at different organizations, I largely agree with @The Wandering Dev Manager but wanted to add more than a comment would allow.
This shouldn't be happening as described. I see a lot of red-flags in both the frequency and immediacy of requests. I suggest having an honest talk with the Product Owner about their current process and how it affects your work. I would also start to look for another job, as this situation might not get better.
If the Product Owner is simply bad at their job, that's actually good - they can get better or can be replaced. Unfortunately, many times situations like this exist because the Product Owner is actually quite good at what they do, but has been forced into certain patterns due to pressure from above. Not everyone can invite their CEO to fire them on every battle. When this is the case, the situation will not improve.
Overall, changes during a sprint are fine -- but you should be prepared for them. I always make sure my product and tech teams pad sprints with enough points to handle "hot fixes" and bugs. When I ran product at a Media company, my teams knew to reserve a set-number of points each sprint -- something always popped up, as that was the nature of our business. Our system worked, because we could always plan for some sort of event to happen. If a forecasted event somehow didn't happen, then leftover time could be used for personal projects, housekeeping, or [gasp!] getting ahead. Handling the last minute features/changes was always at the discretion of the Product Manager, and in consultation with the Project-Manager and Tech-Manager for that team. We always made sure that the Team's morale was a factor as well. Nothing was ever promised to the business units other than a "best attempt to deliver" .
Sometimes, an exceedingly bad business decision is made – and no one realizes this until the sprint has started. This has happened a lot with startups I advise. Handling this type of situation is pretty simple – you have an an all-hands meeting to re-point, re-prioritize, and re-schedule. The sprint is aborted; you start from scratch.
Your business stakeholders may not understand that proper planning is needed for a lot of reasons. It minimizes administrative overhead, it allows interconnected systems to be built in more efficient manners, it allows for foresight and planning in how a solution is designed... There are a long list of reasons, but there are only 2 main take-aways that the stakeholders and Product Owners need to understand:
- You waste more time and money with immediate changes and requests. This method is always the least efficient.
- You hurt team morale and employee job-satisfaction with this workflow. Your developers will become stressed, angered, and ultimately leave.
When the customer is an internal organization, this means the department heads need to discuss. If the customer is an external client, then the company needs to decide if the business relationship is fixable or even justified.