If you are really sure that the injected code can only be executed by the same person who injected it, then it could indeed be classified as "self-XSS", as mentioned in a comment to your question. Apparently to exploit that an attacker needs to rely on social engineering, trying to trick other users into injecting the code themselves and execute it.
EDITED TO ADD CSRF SCENARIO
Anders's answer suggests a CSRF scenario but I don't agree with that (and I don't have enough reputation to comment there yet). However I just realized that a CSRF vulnerability can actually help the attacker to exploit your XSS. Anders's suggested using CSRF to log you in as the attacker and redirect to their page that had been previously infected. This way you'll find yourself executing arbitrary js, but you are logged in as the attacker and executing js on the attacker's private page. That seems pointless to me. The supposedly right option would be to use CSRF to inject the malicious code directly in the victim's page. It would work this way:
- the victim is currently logged in on your website
- the victim visits a malicious website that uses CSRF to inject the XSS in their own private page (for example a POST request to a form that changes their profile settings and put js in the vulnerable field)
- the victim visits their own private page and... now there's injected js there
This of course requires that the form on your website used to inject js is vulnerable to CSRF (for example because the form doesn't require a hidden secret token), so an attacker can force the victim to make a request to your website with serious consequences without the victim's consent, for example changing settings, passwords, or in this specific case injecting js. Read up on CSRF if you need to understand more.