Use the official process.
There's an official process to get staff attention for bug reports and feature requests. Follow the instructions there to escalate a question to staff attention.
Note: When this official process was introduced, moderators were initially strongly discouraged from escalating older posts which didn't fit the current quarter's priorities. However, that is no longer the case. Now, moderators can add status-review to any question, regardless of age, at the moderator's discretion. Questions which don't fit the topics for the current quarter are likely to be assigned a lower priority, but SE staff will at least be aware of them.
If your flag requesting the addition of status-review was declined, then you can follow the tips below.
First of all, it's worth mentioning that an official response from the team is not guaranteed. However, there are a number of things you can do to increase the chances that a bug report or feature request (overall, "request") receives an official response, whether it's your own or someone else's. (An official response can range from completing the request to declining it or dismissing it as by design; this post outlines what you should do if it doesn't get any sort of response from the team.)
If it's someone else's question, one thing you should definitely do is upvote it. Vote scores on such questions indicate how widespread the bug's effect is, or how many people are interested (or not) in a certain feature.
Another thing you can do to anyone's question (yours or someone else's) is edit it for grammar issues, further reasons why a certain request should be completed, or changes made to the system that make the request even more relevant today. This was something I did a few times as the anonymous editor (examples 1 2 3). Just as it does on main Q&A sites, editing a question will bump it to the homepage.
Third, if it's someone else's question, and you have a thoughtful explanation as to why the request should be completed (longer than would fit in an edit without changing too much in the post), answer it and provide your explanation there. Answering will also bump the post, and will increase the perceived interest in the request. (Note that your answer should expand upon the original request, and not be redundant to it.)
A final option, as a last resort for any type of question by anyone, is to contact SE. While this is more of an abuse of the contact form in my opinion, it was actually suggested by an employee as a good way of getting official attention for a request that slipped through the cracks. Personally, I wouldn't recommend doing this unless you tried everything else and failed, and you should refrain from doing this on a frequent basis (only do it very occasionally).
I'd also like to point out what you should not do, as well as give some tips to make your future requests more likely to receive official responses.
Don't repost the request, if it's already been made before. Your question will definitely be closed as a duplicate of the older request without a response, even though yours is phrased better or contains more info. (I personally disagree with this practice, but right now, it exists.) In a similar vein, don't simply ask "when will [existing request] be implemented", as it will also be closed as a duplicate (and lead to no official response).
Don't post a simple, one-line answer asking why the request hasn't been completed yet, without supplying any good reasons for it. This is very likely to just get deleted as a non-answer. Similarly, don't post a multi-line answer that is merely redundant to the request, and doesn't add anything new.
Finally, a little controversial, but purely my opinion: don't put a bounty on it. While this is a great way to get attention for questions on main Q&A sites, from what I've seen, it isn't a good way to get official attention for bug reports and feature requests, which means the bounty rep you spend would be wasted. According to this answer, it's a good way to get community input, but not official input.
And now some tips for increasing the chances your future requests get official answers:
Phrase your request clearly. A good feature request or real bug report is less likely to get an official response if it doesn't clearly explain what the feature or bug is. Be sure to clearly explain it when initially posting your request.
Try and ask for alternate fixes. (This doesn't really address the question, but is a good alternative.) Some bug fixes and new features can be implemented client-side as user scripts, and there are a few users who are adept at writing such scripts and provide them in answers or in a larger collection of scripts consolidated into one.
Post your request when the SE team is active and working. This is approximately Monday-Friday 9am-6pm in U.S. Eastern Time, or 14:00-23:00 UTC (13:00-22:00 UTC from March-November), excluding U.S. public holidays. Posting at a different time will at best delay an official response, and it's likely that other questions posted in between yours and the start of the work hour will swamp the team and your request will fall through the cracks.
Addendum 1: requests relating to specific features that are unlikely to be handled
As development work and priorities continue to develop and change throughout the Stack Exchange network, the following features of SE aren't currently receiving very much development work. As such, even if you follow the steps above, you may not be successful in getting an official response if your request is about one of the following features:
- Chat (all servers)
- Area 51
- iOS and Android apps (no longer officially supported)
Feel free to update this list with more features if they come to mind.
Addendum 2: undesired design changes and other long-time features of the site
As of February 2020, a lot of design changes are being made to the system to better align it with newer Stacks standards, as well as other improvements. Some of these changes may end up removing features of the site that have long been present, and so it's jarring to see them go away.
However, if you file a request to revert a design change just shortly after the change is made, it's likely that your request will end up ignored. It's often the case that you may get used to such changes some time after they are made, and the team is aware of this. (I learned this with the new 2018 mass design changes as well as the 404 polyglot removal on Stack Overflow: while I quickly filed a request to change the latter back, despite lots of community support, it was declined.)
If you want to increase the chances that a request to revert a design change will be granted, wait some time before filing the request. It might be possible that you'll get used to it after a while. However, if you've waited a while and you're still unsatisfied, be sure to clearly state objectively why you prefer the old style, instead of just saying "I liked the old way better".
