Twitter: User Co-Creating or User Co-Opting?

Now that the dust has settled from last week’s Twitter rollback of the reply feature, I’ve been thinking about how Twitter and other services with passionate users incorporate user-generated usages like replies into their core platforms—and when it's healthy co-creation and when it's a risky co-opting of the product by users. If @ replies put a burden on the Twitter service, was user dependence on them the result of a symbiotic conversation between Twitter and its users, or the result of letting users take control of the product without regard for corporate consequences?

I’m not saying Twitter falls into one category or the other—I’d rather not speculate from afar (there are enough folks doing that on the web right now)—but these sorts of features and rollbacks raise questions about how companies and users align their interests. Co-creation can be a fantastic tool for accelerating the rate of feature development in your product, provided you have other competitive defenses (Twitter enjoys a network effect that’s close to tipping to insurmountable); co-opting can cause you to support use cases that lead you to the “Fail Whale”.

In either case, something seems wrong with Twitter’s adaptation of user behavior.

If it’s co-creation, the platform and product strategies may have diverged by allowing the features to get out ahead of the platform’s ability to support them - it wasn’t supplying users and engineers with the right feedback to guide the platform towards where the users wanted it to go. There’s usually time to be deliberate in adsorbing user ideas; for example, Chris Messina wrote a spec in mid-2007 for channels on Twitter that is just starting to take hold - plenty of time to react to support or dissuade users from this behavior. Given the wide-spread adoption of this specification, and how it's used on Summize, these sorts of requirements should already have been incorporated into the platform technologies Twitter is building in an effort to get ahead of user adoption. If the long-term platform won’t support this, perhaps it shouldn’t encourage such behavior by working so closely with Summize.

If it’s co-option, Twitter can learn from some other companies that take steps to mitigate dangerous users. For example, as Ben Lorica showed,Twitter doesn’t limit friends/followers, creating situations where bragging rights exceed utility, while greatly taxing the service. Facebook, facing similar challenges, prevents users from having more than 5000 friends, limiting the damage “power users” can do to the platform. These limitations allow companies to focus on the core business and the majority of their customers. Another approach, one Twitter has adopted, is to work with partners to support needs you can’t deliver, which Twitter has done with Summize to deliver real-time search results.

Whatever is actually going on at Twitter, allowing your user community to engage in a conversation regarding your product development can be incredibly valuable, and ignoring their behavior can lead you to miss a key new feature. However, if you embrace every use of your service, and avoid every complaint about a feature you don’t support, eventually the conversation will become dysfunctional, and could prove disastrous, undermining your credibility and service.