For the publishing community, social reading has been the hot topic of the year. Since 2008, in fact, social features have spread like wildfire. No publishing conference is complete without a panel discussion on what’s possible. No bundle of Ignite presentations passes muster without a nod to the possibilities created by social features. I understand why: in-content discussion is exciting, especially as we approach the possibility of real-time interaction.
Granted, I’m biased. Running a social service myself, I think all this interest is great. The web should take advantage of new paradigms! Social discussion layers are the future! However, there is one important point that all the myriad new projects are ignoring: unless it’s a core feature, most companies shouldn’t build social.
That’s right. Unless social discussion features are the thing you’re selling, don’t build it from scratch. What’s core? Your unique value proposition. Are you a bookstore or a social network? A school or a social network? A writing community or a social network? A content creator or a social network? The distinction is often lost on a highly-motivated team trying to be all things to all users. For all these examples, the social network is just an aspect of the business. It is an important piece of the experience, but most of the time it’s not worth the incredible investment in time and manpower to build it from scratch.
Services, APIs and the Complex Web
We’ve seen this happen again and again on the web. If you’ve ever heard of Get Satisfaction or UserVoice, you’re familiar with the evolution of customer service on the web. Ten years ago companies built their own threaded bulletin board systems (and managed the resultant torrent of spam), so that they could “manage the user relationship.” There were some benefits – you could customize the environment completely, for example. But it took the greater portion of a week to build, and a lot of work to maintain. Today that kind of support can be up and running in an hour with third party solutions. Just ask forward thinking companies like Small Demons and NetGalley, who have embraced these services.
The same can be said of newsletters. For years newsletters were hand-coded (or text-only) and sent from corporate email accounts. Unsubscribing was difficult. Getting email accounts blacklisted (because they looked like spam) was common. Today everyone uses MailChimp, Constant Contact, Emma, or a similar service. Even if you hire an agency to design and manage a system, they’re likely white-labelling and reselling a service like this to you. Companies no longer build a newsletter service. Now you just use an API to integrate your newsletter signup form with a third-party database. Design your newsletter using one of their templates, and let them do all the heavy lifting for email management, bounces, unsubscribes, and usage stats.
There are other examples. Who stores video and builds their own player? Instead we upload it to Vimeo, Brightcove or YouTube, customize the settings, and let the service tell you who watched it, handle storing the heavy files, push player upgrades frequently, etc. Even web hosting itself has become a service that people sign up for – in many cases setting a project up on AWS (Amazon Web Services, essentially cloud computing) is faster and easier than acquiring a real hardware server and configuring from scratch.
The rise of these third-party solutions are a testament to maturity and complexity of our digital world. Specialization makes systems more stable and dependable. Sure, any time you partner with a service there are risks. But I’ve seen so many publishing projects with social features miss their launch deadline or trash their social features before launch because they found they couldn’t get it built, that it’s hard to watch them spin their wheels over a perceived need for control. That’s a mess of work for something that isn’t the center of your business.
Publishing Focus and Third-Party Opportunity
This move to third-party social solutions should start happening with all the education, journalism, authoring platforms, writing communities and publishing projects currently in development. Although it sounds simple to just add discussion into content, the devil is in the details. Obviously the front end – the process of adding a comment – takes some work, and the estimation for that is fairly straightforward. But what about the paradigm that people use to connect? Are they following people in a Twitter paradigm, or is it a group-based, reciprocal model, like Facebook? Who can delete comments? What can you manage with your administrator dashboard? Are servers ready to scale with peak activity? What kind of stats can you get on how your audience is interacting with your content? Most of these issues don’t relate to the core business.
In the end, it comes down to the project definition. Is it a bookstore or a social network? I’m guessing nine times out of ten it’s a bookstore first, with additional social features. Focus on controlling the content and making the sale, be unique via curation and selection, and add the rest of the social features in using APIs and third party solutions. Then tweak the experience based on what those third-party services can tell you. That way you have the freedom to experiment and tweak the social options you offer your users, but still focus on your core offering. Everybody wins.