At its core, the purest unit of Twitter is a tweet, or a grouping of 140 characters that can be shared. This serves as the nerve center of everything the company does. Any company that wants to succeed needs to find its core atomic unit: for Google, it’s the search box (look at its front page); For Facebook, it’s the user profile; For Instagram and Pinterest, it’s the picture; For LinkedIn, it’s the business card (or business profile); For Foursquare, it’s your location. Startups that want to follow in those companies’ footsteps need to think of what is the most basic component that remains when they strip everything away from their product.
That kind of reduction seems easy but is actually a huge challenge as this core component then needs to be different enough to be able to succeed. The most successful companies are the ones that can find a unit that resonates at the smallest level. The core question anyone should ask at that stage is what can I remove from my idea? The more you remove, the clearer the picture becomes and the more focused the offering can get.
But removing does not mean throwing away. It just means temporarily putting things aside until you can figure out what makes the product successful. Once you cannot remove anything more, you have the basic unit for your product. While Twitter did this before the product was out in the market, we can see similar elaborations in products like the Apple iPod shuffle. When Apple could not progress the iPod by extending what it could do, it went in the reverse direction and figured that, at its core, the Apple had been about the song as a core atomic unit. So it produced a product that could play songs.
The next step is how to make that atomic unit work. The 140 characters Twitter has needs to be posted so a box to enter the data and a button to post it is necessary. And once it is posted, anyone reading it needs to know who the message is from so the Tweet now needs to have a name attached to it. This is an important distinction as people look at Twitter as a social network like Facebook but the reality is that Twitter is centered around the message, not the individual.
But here again, one has to be careful about not overloading the functionality. Successful products should be easy to understand. For example, if you were to take the original Twitter interface and the original Google interface, the whole of the difference in the initial experience was encapsulated in what was on the button next to the text entry box: for Twitter, it was “send” (it was eventually changed to “update” and then “Tweet”), clearly highlighting that the utility was to send the text entered into the box onto the internet; for Google, the same button had “Search” (which has morphed into “Google Search” over the years), making it clear that the utility was to find something that had been entered in the box.
The same can be true in hardware: the initial iPod shuffle had a button to start and play music, skip tracks, and change volume, reducing functionality to its bare essential.
So when you’re thinking past the atomic unit you’re creating, you have to think about what that minimum group of functionality you need to add to it in order to make it work.
Once that core unit has been define, the next challenge is figuring out how to add utility to it. For Twitter, it started with the ability to reply to a Tweet and “Favorite” a tweet; then it was expanded to the concept of retweeting (or sharing a tweet). Over time, they layered in more functionality but always with the concept of enhance the core unit.
Because Twitter was about communication among friends, the concept of following and followers was born. Here again, the distinction with a social network arises: While Facebook wanted to make sure that the relationship between two people was agreed upon, requiring from both party for confirmation, Twitter looked at those relationships as much looser, similar to one being a fan and thus did not require an agreement between all parties.
Note that these new functionality steps were not in the initial package, they were added progressively. The reason for taking that approach is two-fold: first, it ensures that your customers are not overwhelmed with new functionality on day one, making sure that the product is easy to use and comprehend. Secondly, it gives developers time to think through the different portions of interaction and develop them based on demand.
As the product evolved, the company had to think about how to improve the experience. This meant balancing the need to remain true to its core and the wants of the users. In 2007, developer Chris Messina introduced a convention from an earlier internet chat system (IRC) on Twitter when he asked fellow users if they would be interested in using a # before some text to make it easier to search through tweet. Thus the hashtag, now thought to be an essential feature of Twitter, was born. It remained a geeky thing for a couple of years before the company started to incorporate it in its design. A 2009 redesign brought popular hashtags into the navigation bar but it wasn’t until 2010 that they became clickable within the discussion flow.
This kind of listening to the customers and assessing what should and should not go into the product makes the core of product management focus and the slow cautious approach to the hashtag integration shows how even a quick-moving company like Twitter can take a long time to make radical changes to its product offering. Here, the lesson for product managers may be that small groups of vocal users may be right but requirements should be dictated by a critical mass of users.
There comes a point in every product life where the core unit of a product may require expansion. If you remember, a few weeks ago, we talked about how Twitter cards allowed the company to expand beyond the 140 characters limit. to recap, cards are extra information carried in a message when it includes a URL. That extra information can then be presented by the Twitter interface to offer a richer experience that may include pictures, videos, or more.
Once again, we see a company that is deliberate in its approach to growing its offering. Looking back at its core unit, it has figured a way to wrap it but not change it, retaining the original purity while extending its functionality.
When Twitter first came out, its core unit was aimed at text messaging. At the time, MMS (the version of SMS that allows you to attach pictures) was already common but Twitter decided to stay close to the text medium (that core unit). The original product could have easily incorporated images but it did not. Again, that essential purity gave it its start but the fact that extra content could be loaded at the time highlighted a potential path.
Twitter could have added that extra functionality in the tweet but decided to put it one layer above it when it implemented the new functionality: this is a smart move as it keeps its core intact. The lesson for product manager is that the core should not be changed if it has been designed properly.
Twitter provides some very valuable lessons into how a product ought to be built. Its success in the marketplace and among consumers shows that small unit, properly expanded, are the best way to go when you want to build a service that will work at scale. Product managers would be served right to visit their own product and figure out what that core unit is. And if they cannot find it, they may have to deal with a large issue as to the future prospects of their product.