deciding on priorities for new features

we released a very limited version of our product but it misses lots of functionality.
Our income will be based on retailers and there are certain functionality they will be looking for. And of course they will be looking for users base.

The product is kind of aggregator and its power is coming from both the content & content providers and the number of readers.

On the other hand current users are also looking for certain functionality. if we continue as this, we would possible attract more users. At the same time if we can enable our retailers they will also provide more users.

At this point we need to decide on priorities ?

customer derived sounds great but it has a cost of development, should we postpone our income till we get a proper user base ?

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.

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.

As there no exact rules defined for this the best practice usually says

• Do the major bugfixes first.
• After that sit down and break down the features requested by the most revenue they will generate. Assign development costs and times to those features
• Then break down features most requested by customers assign costs and times to those

Once you've done this it will simply boil down to what is the most cost and time solution you can come up with that will generate the most revenue and yield happiness to most customers. Then you implement that subset.

Now as far as forgoing revenue I wouldn't if I didn't have to but that's me.

Developers sometimes do not see something obvious for users. So you need to get some feedback about your product.

• The easiest way is to ask people to review it. First ask your friends then ask people on related public forums.
• See what features competing products have. Check which important ones are missing in your product.
• Search the web for discussions about competing products especially look for complains about the missing features.
• Start a beta program and give free license anybody you got feedback from. Provide some questionnaire with with field 'desirable features'. See some useful tips about running beta http://www.joelonsoftware.com/articles/BetaTest.html
• Its pretty easy to add a forum to your website (there are free scripts for it like http://www.phpbb.com/ ) Then start 'wishlist' topic and invite people to discussion.

In addition to following the excellent advice given in the previous answers, keep this in mind: USERS THINK VERY DIFFERENT.

Make sure you do some 'hallway testing' and discuss whatever you plan to do with unrelated users / friends / spouse. Engineers are rational thinkers - and deeply involved in product development, this skews the priorities.

Unrelated people don't care about architecture, framework features etc - they have an unobstructed view of how they envision a desired benefit. I can guarantee you that this will give you some great insights that you otherwise might have never thought of (and missed).