Maybe I gave the wrong impression - I thought the UI for choosing feeds was well implemented, but having to choose is itself laborious, however pleasant the UI for doing it. (And as I mentioned above, "most popular" was not in my case a helpful heuristic.)
Put another way - if I had built this, the main reason I would have included Google Reader import in the free version would be so people could experience the value of my app without having to think - about what blogs to subscribe to, or what existing subscriptions to keep. Putting the paywall at this point in the first user experience removes that benefit in cases like mine. I might think about the benefits of your app and come back and upgrade - or I might forget - but you could have had me as an impulse buy.
I see your point crystal clear. But what happens when I don't make you choose a max of 64 feeds? I still have to fetch 100% of your other feeds, which could be in the hundreds. And I have to do this for every single user, which is currently in the thousands (ohh, my poor server). It just doesn't scale with my economics. If I were Google, sure, I could just throw money at more machines. As it is, I'm stuffing envelopes full of cash and sending it to Linode.
Ideally, I'd make all feeds free and updated every 5 minutes. Realistically, if I force you to choose, I can perform that much better for everybody else. It's a trade-off which I try to stack in my favor by giving the user an easy-to-use UI to activate different feeds as they choose under the standard account.
You could pay $12 a year and get unlimited feeds. That would make both of us very happy. :-)
First, just give them 64 feeds and tell them about it on some form of status bar. The "updating your feeds 63/64" progress bar, but maybe yellow with "We're only updating 64 of your feeds. [a href="why-premium/"]Why?[/a]"
Also, you can choose those 64 feeds to update as a union of what they have subscribed to and what you're currently already having to fetch, thereby making the necessary amount of work for each new user theoretically less in the best case, and no worse in the worst case.
Comments
Maybe I gave the wrong impression - I thought the UI for choosing feeds was well implemented, but having to choose is itself laborious, however pleasant the UI for doing it. (And as I mentioned above, "most popular" was not in my case a helpful heuristic.)
Put another way - if I had built this, the main reason I would have included Google Reader import in the free version would be so people could experience the value of my app without having to think - about what blogs to subscribe to, or what existing subscriptions to keep. Putting the paywall at this point in the first user experience removes that benefit in cases like mine. I might think about the benefits of your app and come back and upgrade - or I might forget - but you could have had me as an impulse buy.
I see your point crystal clear. But what happens when I don't make you choose a max of 64 feeds? I still have to fetch 100% of your other feeds, which could be in the hundreds. And I have to do this for every single user, which is currently in the thousands (ohh, my poor server). It just doesn't scale with my economics. If I were Google, sure, I could just throw money at more machines. As it is, I'm stuffing envelopes full of cash and sending it to Linode.
Ideally, I'd make all feeds free and updated every 5 minutes. Realistically, if I force you to choose, I can perform that much better for everybody else. It's a trade-off which I try to stack in my favor by giving the user an easy-to-use UI to activate different feeds as they choose under the standard account.
You could pay $12 a year and get unlimited feeds. That would make both of us very happy. :-)
You can make this much easier on yourself.
First, just give them 64 feeds and tell them about it on some form of status bar. The "updating your feeds 63/64" progress bar, but maybe yellow with "We're only updating 64 of your feeds. [a href="why-premium/"]Why?[/a]"
Also, you can choose those 64 feeds to update as a union of what they have subscribed to and what you're currently already having to fetch, thereby making the necessary amount of work for each new user theoretically less in the best case, and no worse in the worst case.