In the early days of Twitter, which was known as Twttr at the time, there were two ways you could view data (SMS & Website) and one way in which you could put data in (SMS). If something interesting occurred to me, I would type my 140 (or a few more at the time, depending on the length of username - they standardized it later on) characters and send it off to 40404. Anyone who replied or typed their own message would show up in my SMS inbox. I could also go check what’s going on in their web interface (which, if I remember correctly, only included a public timeline to start…friends only timelines came later).
Things were pretty slow those days and a few of us dedicated exhibitionists would send the occasional message, but mostly, as Narendra aptly put it, Ev was our Tamagotchi. Lucky for all of us, Ev has an insanely interesting life. 
If things would have stayed that way, I hardly think Twitter would have lasted very long. Now we know, it didn’t and what they did next is the most interesting part of the story…as well as a lesson for people building web apps everywhere.
It is at this point that most companies make one of a couple of mistakes:
- They throw in the towel, scrap what they are doing and build something entirely different, usually using the same technology. Riya did this. Goowy did this. This can be met with great success, of course, like in the example of Flickr’s directional change. But I would also caution that these types of changes mid-stream can be the lack of deeper thinking about the real problem.
[Lucky for us, Twitter was an interesting enough concept to realize it's potential. It had a small following, but you could see the love already.]
- They try to build in more features…more “reasons for people to stay”. I’ve seen this a number of times and it usually follows this conversation:
Bob: “We have high traffic, but nobody is sticking around.”
Alice: “I keep hearing the same thing. They just don’t have enough to do.”
Bob: “Well, then we should build in more things for people to do.”
Then the fortress continues to grow and, in consequence, it becomes less and less attractive for a person to sign up.
Twitter could have done this. They could have built in groups or additional short codes or created all sorts of ways for people to use their SMS. But they didn’t.
Instead, they followed a THIRD option: they built more onramps.
They added Jabber integration for sending/receiving messages, and added sending messages to the web interface. They also allowed you to keep track of just your friends in the web interface. They also released an API, allowing for others to build many more onramps.
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…
This is an important step.
Thinking about it in the way of ‘On Ramps’ could lead you to asking these types of questions:
- Is there another web app that we can integrate with? [We've found that partnerships can be uber powerful in the early stages. Think about Plaxo's Address Book widget. I've seen this used by many new startups.]
- How does my app interact with various interfaces? How simple would it be to have it work in more? What would the minimal functionality be while still being useful? [If you are a time tracking app, could you build SMS integration?]
- How simple have I made life for those using my API? Have I thought about this:
- What is the users offline experience? [Firefox looks to be developing exciting new ways for people to interact with their fave online apps]
- Have you designed your app to be simple enough to adapt to a text adventure? As Michael Buffington put it:
Quite bluntly, if your web application can’t easily be adapted as a classic text adventure, your application has serious problems on multiple levels. Applications that can’t be easily adapted likely suffer from application structure and design problems and UI dependency, to organizational politics and bad decisions.
Think really simple command line-type interface (do the YubNub test, if you can simply build command lines for user functions in YubNub, you are a-ok). Simple platform…then build stuff off of your API.
Building more ways for your customers to access your app is better than building more things to do in your app…especially early on. If you want to increase adoption the right way, make accessing your app as easy as possible.
View Tara Hunt's profile
9 Comments
I love this idea of “build more onramps” as a product strategy. Most of us know that our apps need to be plastic at the user experience level, and that we should cultivate opportunities for co-creation with our users. The onramps directive helps build those outcomes into the DNA of our app.
Hi Tara,
Nice figures. Like the overall idea.
Building more “ramps” for people to access your services can be very useful. It certainly helped Twitter and if it used to be mainly SMS messages to people it is much more now.
“Semantic HTML” part of picture, however, does not “stick” well where it is in the picture now. I would call that circle “Data API” or “Data Format” instead. You need an API, but do you really need to choose a particular representation here? Is HTML the best carrier for everyone?
While it can be a useful + interesting exercise to build an application (or its Data API) using microformats, RDF or any other technology, there needs to be a good motivation why - how the architecture ‘d benefit from this “link”.
In the top part of the architecture figure you’re looking at connecting different applications together, human customers enter the picture later. Therefore one can use simpler data formats , e.g., JSON (used by Twitter already) which require less overhead and make life easier.
P.S. There is a book “Building Scalable Web Sites” by Cal Henderson based on Flickr development experience. Can be interesting when talking about scalable and distributed architecture.
Wow, Tara - I really like this post a lot - very enlightening and thoughtful. I’m definitely going to apply it to some of the ideas I’m working on now.
great post. i was listening to jason calacanis interview evan williams this weekend and evan stressed that many startups want to create something really “big” when actually, a very simple “small” idea can be huge, if you keep it focused. and build the onramps, of course.
While I generally agree with the content of this post (and think it’s a great point), I’d like to point out that the “create more onramps” approach has actually caused a number of problems for Twitter.
1. When an onramp shuts down due to technical problems, you lose users who have become dependent on those onramps. For instance, the only way I typically use Twitter is via the AIM bot. AIM bot is broken, no clue when they’re fixing it, so I’ve largely stopped using Twitter. Adding onramps without fully developing them to last, stay robust is no different than adding a bunch of new features, and then you’re back to your point about feature addition.
2. Onramps = usage = scalability issues. Twitter, at least to me, has basically suffered the Friendster Folly - successful to a point of a nearly uselessly slow site. I can’t believe this didn’t have something to do with the fact that there were so many onramps for users to submit overwhelming amounts of content.
3. Changing direction mid-stream based on user reaction/acceptance isn’t better or worse than adding onramps. (The implication, however true, from your post is that onramps are better than direction change) It’s a tough call to make and there many, many variables that go into a decision like that. Listening to users (or listening to the silence) is important here. The Twitter example will be an interesting case study over time, I think. After all, does something like Twitter work when there’s tons of people on it? I’ve heard so so 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. If the site had maintained a smaller group, stuck to SMS only, and not thrown open the doors to anyone and everyone who has any sort of internet access would they continue to grow, but in a way that keeps users around for longer? I dunno… we’ll have to wait and see.
Just a few points to ponder as we talk about a very interesting topic!
Hey Jake,
Thanks for your thoughtful comment.
Now, I don’t know if Twitter’s gaffs are a problem of Onramps or just the result of building those Onramps without preparing for the success of them. I would argue that the Onramps are wildly successful and that their mistake was in predicting that success.
As for your #3. I agree that it can be successful to change midstream, but it is very very rare. However Onramps to a simple platform is almost always successful.
I don’t think either of us knows the answer of the future of twitter. Now comes the times when they should be thinking of features to implement to ease the pain of message overload. And features for more user control. But that’s because they’ve gotten past the first phase, which is more my point:
Onramps are necessary to early adoption.
Cal’s book is brilliant and I’m sure he would put what I said above in much clearer development terms. He’s brilliant. I chock it up to the fact that Cal see’s the world as “What is the simplest way I can accomplish this” at the same time he is thinking “…without doing a bunch of work to re-do it down the line.” (but that secondary thought is secondary)
Thanks for the tip on the semantic html…you are right, there are many conduits to consider. I’m not sure about RDF, though. It gets pretty heavy then. But then again, I am not a developer…I’m a marketing hack who knows a thing or two about web app architecture because of my proximity to it.
Sounds like we’re talking basically the same place. I totally agree with this point:
“Onramps are necessary to early adoption.”
…to which I’d add:
“Just make sure each onramp is fully flushed out before moving to the next one.”
But as far as point #3… I think rarity can be associated with the point in the process at which they make the shift. If they’ve already gotten investors, spent their money, and have specific deliverables/concepts they’ve promised, then I totally agree with you. But in an age where software can be developed in days, I think we are seeing/will see more shifting based on user feedback and overall interest. (This is what makes this time so great! :))
Tara,
Great post, thank you.
9 Trackbacks
[...] cruised past this post about building entry points to your apps from HorseCowPig this weekend. Sent it off to some of my favorite uber-geeks. Reaction [...]
[...] ::HorsePigCow:: marketing uncommon » Case Study: Data Onramps “Building more ways for your customers to access your app is better than building more things to do in your app…especially early on.” (tags: webapps web2.0 strategy case-studies twitter) [...]
[...] Tara talks about onramps and the usefulness of your app as a command line program. [...]
[...] I’m sure there’s plenty of people ready to point out all sorts of systems that already do something like that with expenses. The larger point here is to apply that kinds of user interaction to other, boring systems. And, of course, to make sure systems and platforms have open enough APIs to work with desktop widgets. Tara Hunt recently wrote up about all you need to know on the second point. [...]
[...] quickly retrieve data, like addresses from local search (as in the example I concocted above for a Yahoo!Local search), to send in information (i.e. sending your timetracking to Harvest, or a command to [...]
[...] the past couple of years talk like I’m some sort of developer or something. Talking about Onramps and Command Line Interfaces and Microformats et al. I don’t just hang out with the developers [...]
[...] recognize twitter as a tool to do something that would be very difficult by any other means. The multiple on-ramps provided by twitter mean that an activity that would be pretty tricky to do mobile…like [...]
[...] Enough about Backpack… what should you do if your app falls into this “sweet but not quite as convenient as I would hope” category. Tara Hunt writes about what Twitter did in an excellent post. [...]
[...] for community implementing quantity-enhancing features like anonymous commenting? Now, I understand the need for Onramps, but Onramps and barriers to entry are not the same thing. Onramps/offramps are the ways that you [...]