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.