The questions I have while working on my project is when to introduce the mium in freemium.
(1) Would you be wise to introduce the premium version at launch with the free version if there is enough value, even without that established free base to leverage off?
(2) Should (being the emphasis here in refering to good business conduct). Should a business have paying customers when a product is in beta version and isn't yet completely tested against up and down times, bugs etc...?
(3) If one were to go the route of having free users before having paid users, should the free users have access to what may be removed and added to the premium release in the future, for the initial purpose of gauging whether there is interest for certain features over others?
To elaborate on that last concern. If users do get to use everything for testing purpose, am I going to get into one of those weired battles with community when certain things get shifted over (even if everyone was notified at the beginning that this would occur).
(1) Your "launch" should be introducing your premium version. In other words, the day you deploy your billing code should be the same day you leave beta.
(2) Let everyone use the site for free in beta. What you lose in concrete revenue you make up for in free bug reports, feature ideas, and feedback.
(3) Tell the free users the beta is ending and they'll soon have to pay. Feel free to give free accounts to some of the prolific community members, but don't feel bad charging people for your service. It's worth charging for - that's why you built it, right?
My own experience is with software that was free for a year before my first sale (though I made it available for sale pretty much near the start). So I did do what you are thinking. But I developed it entirely in public: the first version (released) took me 2 hours to write. This approach was great for countering my perfectionism.
(1) Yes. You don't need a free version to sell stuff. But what does
"leveraged" mean in your case? If it's a network effect, where your offer has no value unless there are already users (e.g. a dating site), you would need some way to build up users.
(2) All products are incompletely tested... it's an opportunity to show customer service... and version 2. There's a question of degree here of course. You're right, you do have a chance to try it out on free users - although bugs are just as annoying for them as for mium/fee customers. Maybe the way to think about it is: are they paying for the benefit you offer, or for the absence of bugs? People complain, but they still buy - because they know no-one is perfect. Provided you treat them with respect, they may even like you more because of it.
(3) People don't like it if you take something away, especially if they started to rely on it. It creates bad feeling. I think a free trial (time limited) will give you the info you need.
I can relate to the perfectionism syndrome. But the release early, release often theme seems not a good counter while going at paying users. Sometimes that early release simply isn't worth paying for yet, it may take several iterations to get to something that is worth a package fee. I agree all products are incomplete both in testing and in functionality and that should be used to temper perfectionism.
Though there seems to me a difference between releasing early to get people to use it, and releasing to get people to pay for it. The release early and often theme I tend to think should not be broadly applied to both.
Perfectionism aside...thanks for answering my questions.
Sometimes that early release simply isn't worth paying for yet
If so, no one buys it - no problem :-) (assuming they can evaluate it first, e.g. free trial).
Though there seems to me a difference between releasing early to get people to use it, and releasing to get people to pay for it.
I don't know. You could be right. But both require a benefit to the user; and both exact a cost from the user - of learning; time and effort of changing behaviour to integrate it into their life and apply to their problem; constraining other choices/products to integrate with the product (depending on what kind of product you have). It's natural to think price is the cost of something - but it's simply not. (It's true though, that customers also think of it that way).
hehe I'm getting a bit of the answering-the-comment-while-being-edited syndrome :-) It's a bit disconcerting seeing from the other side.
1 - Release the paid version when it's ready. Early cash, and free users don't care if you have a paid version.
2 - No. But let's face it, no complex software is ever finished. And it depends on the bug. Someone wants to use Lynx to access your webpage? A chinese user on an unpatched Windows 95 behind the great firewall doesn't see icon next to "post a comment"? Wisely balance the factors and just do it when you think it can make money for you.
3 - No. For testing purposes (I presume you mean the user is testing the app to see if it works for him), just make it clear that feature X and Y will be removed in Z days.
(1) Would you be wise to introduce the premium version at launch with the free version if there is enough value, even without that established free base to leverage off?
(2) Should (being the emphasis here in refering to good business conduct). Should a business have paying customers when a product is in beta version and isn't yet completely tested against up and down times, bugs etc...?
(3) If one were to go the route of having free users before having paid users, should the free users have access to what may be removed and added to the premium release in the future, for the initial purpose of gauging whether there is interest for certain features over others?
To elaborate on that last concern. If users do get to use everything for testing purpose, am I going to get into one of those weired battles with community when certain things get shifted over (even if everyone was notified at the beginning that this would occur).