Everything you do is a compromise. Some of these are obvious:
"Customer Foo has a big problem, and we're stopping everything to fix it!"
"Well, you asked for more X and you want faster Y, but we only have two more weeks before we cut the release. So which one do you want for this release?"
Others are not so obvious:
"Here are two faster processors. Does that help our performance?"
(HINT: Does that help our performance doing what? There are a lot of options for what to try first here.)
"Did you test this yet?"
(HINT: This means "I really hope you hit this one and decided that it was more important than the other thing you were going to test".)
It's not that you can do only one thing at a time; it's that your total capacity doesn't grow just because your customers (sales, support, product managers, your own itches) have desires. In general this is an accepted thing in software development:
resources x time x productivity = output
The trick is that sometimes the conflicts get lost. If a customer asks for something one day, and the next day someone else asks for something, it can get hard to recognize that you're approaching (or passing) the tradeoff point.
It's all too easy to get into a game where the most recent request is a bully and pushes the other requests to the bottom of the queue.
Only with transparency can you truly make the tradeoffs. Scrum solves this with the backlog. XP solves this with 3x5 cards. The trick is helping the team - all your customers - understand what they're asking for. A request is asking that you do something, and also that you not do something else. Understand that you're committing to both parts of that when you say yes to a request. With that acknowledgement you can work toward balance, and get some of everything you want.
If you're really careful, everything will work well not only on its own, but together to satisfy all your customers.