A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
It is easy to go from v1.0 to v1.xx...
But how do I introduce a completely rebuilt application v2.0 so to say?
Should i keep all my links and pad files and just put new exe file for download?
And also, what should I deliver to people who thought they were buying 1.xx version? Can I just send them ver 2? I mean, although it is better it is not what they were thinking they were buying anyway... ?
Puting a notice on site 'there will be a new version in 2 weks' will efectively kill sales in those two weeks - everyone would just wait for new version.
>>>> what should I deliver to people who thought they were buying 1.xx version? Can I just send them ver 2? I mean, although it is better it is not what they were thinking they were buying anyway... ?
IMHO I think you should deliver version 1.xx to those who request it and when the update is available, give them a choice to get it or stay with version 1.xx.
>>>>>Puting a notice on site 'there will be a new version in 2 weks' will efectively kill sales in those two weeks - everyone would just wait for new version.
I agree, risking to kill sales is not such a good idea. I would just keep selling the old version and then seed the update to all of the existing clients of the old version. Putting this notice on your website before the actual launch will indeed have a negative impact
Wednesday, June 05, 2013
Is the price of the new version any different from the old one?
Wednesday, June 05, 2013
I don't recommend pre-announcing before absolutely everything is finished and tested.
In the past I did this. The reasons varied, but it would be something like a competitor issues a new feature and a customer asks about this and I say "The new version has this". Now the customer wants to know when the new version is out, and will decided to "wait and see". This customer will also blog his "inside scoop", effectively outing the news: "Program X has a new version coming that will feature Y." This rapidly gets picked up by the forums where your customers and possible customers hang out.
Then, to stop sales from stopping then you absolutely have to publicly acknowledge there is a new version, and promise free upgrades to everyone when the new version comes out. The alternative is to have sales drop off severely.
What happens then if program was still under development, is that during alpha or beta testing you find a serious workflow bug and decide it needs a different approach to a subsystem. Or you start cutting corners to get it done, which creates more problems.
So you finally release coming 2 years after word got out. And you have to give free upgrades to everyone.
I do think you need to have a "grace period" where people who bought recently get a free upgrade. Most well thought of companies have something like this. It will result though in a few emails from customers "The grace period is 90 days, but I bought 91 days ago, that is unfair." So to stop them complaining you give them a free upgrade. Then they tell their friends. Now the 92 days ago people are encouraged to contact you.
The number that will email and beg is quite small, but they can take up a lot of time, or force you to be argumentative if you don't just give them their free thingy. When I do this I like to make clear it is a special favor for them only because they are a good friend and that it is not policy. That stops them from telling all their friends to come and ask.
@Scott: We used to offer a grace period, but now have a year of support and upgrades factored into the price of a new license. Also, a renewed support contract commences from the date of expiration of the previous one, so technically customers have a 364 days grace period with respect to upgrades.
Works well for us; YMMV.
Saturday, June 08, 2013
I am in a process of doing precisely this - major version increment. Being B2B with relatively wide user base, such move can't be done unilaterally, so we did gentle "investigation" on how users will take it, then made several announcements, then started to work on it, and only at the final stages made an official statement of future shift. All this is accompanied with public beta to licensed users or those with evaluation trial. Making a statement without concrete stuff is a very bad idea. More than that we guaranteed that current version will not die and will be maintained until it simply becomes irrelevant for which we will work very hard.
However our case is far from "complete re-write" like you mention. Shift from 1.0 to 2.0 presuppose significant additions and improvements, some additions are quite radical. But interfaces DON'T change, they expand. User experience improves, gets richer but DOESN'T change. I personally hate when people re-wrap the UI and sell it aka Windows9, so I wouldn't do this to others. And if you are in a position when you found a really big mistake and must re-do totally everything - don't call it the same name. Start fresh product or even brand. IMHO.
So, if you are planning to deliver totally different code base to your users you should take into account the possible impact. Try to cook a frog by dropping it into a boiling water, or put it carefully into cold water and heat gently. Which do you think will work better for you?
Sunday, June 09, 2013
I would agree in offering a grace period that allows new users to get the 2.xx version free, without mentioning that a new release is coming. This will allow you to continue sales as normal and you can focus on completing your 2.xx version and then once you have completed and are satisfied with your latest update you can announce it to your end users and mention the grace period then.
Monday, June 10, 2013
i dont quite understand this question. you mean how to update new versions of app? i just download the new one.. haha
Thursday, June 20, 2013
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz