If I understand correctly, you have two target groups for your product. There are current users, your "early adopters" and perhaps beta testers; call this group U. Then there is a new group, the retailers (call then R) which you wish to attract.
If both U & R wanted the same features in the same order life would be much easier. The conflict comes from the fact that they have potentially differing needs and priorities. You are faced with the universal truth of economics that it is impossible to satisfy unlimited desires with limited time and resources.
Assuming you have a minimum viable product (MVP), then my recommendation is that all priority decisions by couched in the light of the vision you have for your product. In other words what do you see as the product you want to have in 1 year, 3 years etc. U & R can't give that to you since they are unlikely to know what the product could be, only their comparably provincial and limited perceived needs.
First write down your vision and insure you can clearly articulate it. This is key.
Now as you go about prioritizing feature requests, do so in light of the "solution after next" idea.
SOLUTION-AFTER-NEXT (SAN) PRINCIPLE: Think future solutions for the
focus purpose and work backwards. Consider the solution you would
recommend if in three years you had to start all over. Make changes
today based on what might be the solution of the future.
In other words, is the tactical step you are about to take in alignment with your strategic goals?
As an example, suppose you were Apple producing iPads and a big customer wanted you to put a bunch of extra connectors on the side like a lan, usb, firewire etc. This would conflict with the goal of having something beautiful, thin and light. You should then re-think the request in terms of your goal or ascetic beauty and ask "is there a way to provide connectivity without adding a bunch of connectors?" You might decide you could produce an "expansion cube" that sat on a desk, had all those ports, and communicated with the iPad wirelessly.
If you can insure that each feature request you undertake is moving you down the path you wish to go, you should do reasonably well.
Of course you need to temper this with the need to address any "show stopper" bugs that surface in an expeditious fashion.
