Tara posted an interesting thought recently about Twitter’s creation of multiple access points (aka "onramps"), rather than additional features.
As time has gone along, they’ve continued to build onramps before features. In fact, their lack of features has probably helped rather than hindered their growth. It’s as simple a concept for new users today as it was a year ago: tell your friends what you are doing. And, in fact, they could keep it that way, allowing for more and more development on their API. People could even build businesses around Twitter, strengthening it’s position as a powerful platform…
Inherent in the post is both the argument for why this is a good idea, as well as the seeds of why this approach can actually cause problems. I’ve outlined three points of discussion that Tara’s post prompted.
Scalability Issues
Onramps = usage = scalability issues.
Twitter has suffered the Friendster Folly – successful to a point of a nearly uselessly slow site. Around the point of SXSW, the site was taking scores of seconds, sometimes a minute to respond. Remind you of your last experience with Friendster?
Reliance Path
Twitter’s biggest problem for me is that I tend to use the AIM bot to post as my main onramp/entrance point. When the bot was non-functional for a while, I stopped using the service. I’ve not been back until today when I noticed it was working again (as part of the testing for this very blog post). Further, the AIM bot has always been… a marginal implementation. I love the addition of onramps, but only when they’re added in a robust, well-planned, well-executed way. I’d much rather have two bulletproof choices for posting content than ten marginally implemented methods.
Onramps vs. Re-tooling
In a world where launching tools (and the businesses they’re based on) is increasingly fast and easy, it’s even more important to watch what users are doing with your service and respond accordingly. Changing direction mid-stream based on user reaction/acceptance isn’t better or worse than adding onramps, nor are they mutually exclusive. It’s a tough call to make and there many, many variables that go into a decision like that.
The Twitter case study will be an interesting case study over time. Is Twitter inherently better when there’s a smaller number of people on it? Does it need to combine new features (better group functions, for instance) with the additional onramps?
I’ve heard so many stories of people saying that they loved it when they only got a few updates a day, but now they’ve cut it out all together because it’s just too much. When I see so many people using "@Jimmy" to respond to other twitters (which is entirely pointless and confusing if you’re not @Jimmy), it screams to me "I need a better connection feature!", not "Give me another way to post more @ messages!"
To be completely clear, I’m a big fan of additional access points. I think Flickr’s API (and the sites and tools and businesses built up around them) is absolutely brilliant. But from my foggy memory of how Flickr grew, it was a combination of access methods + appropriate new features + stability.
courtesy of our friends at 
I’m more than a little disappointed with Amazon today. If you know me, you know my crazy deep love for amazon. They’ve had minor mis-steps over the years, but nothing as big at the current one:
