Posted by Tom Grant on March 16, 2010
I swore that I was not going to say anything further. I really, really tried, but I'm going to have to throw away the little plastic medal that says, "Two Weeks And No Buzz." Here's a must-read quote that a colleague forwarded to me:
So why exactly did Google Buzz launch with some key social features missing? Jackson said that while Google employees were testing out the product internally, they never had much desire to mute any of their coworkers, and that their email contact list closely matched the people they wanted to follow on Buzz. Obviously, that wasn’t true for most people once the product was released outside of the Googleplex. Which is why Google is considering pre-releasing new Buzz features to a few thousand opt-in users long before they’re rolled out to the public.
The short version: "It worked for us inside the firewall, so we never thought it'd have a problem outside the firewall." Of course, an enterprise collaboration tool is a wholly different kind of solution than a social networking tool, so the requirements for the former do not completely cover the latter.
Rather than harrumph further about this epic user feedback fail, I'll use this as the occasion to point out how tricky the requirements of collaboration tools can be. Everyone uses collaboration tools. In fact, they're extremely durable technology investments, in both good economic times and bad, among big companies and small ones. (Here's a great report that discusses software priorities among SMBs, in which collaboration appears at the top of the list.)
Unfortunately, not everyone is using collaboration tools to solve the same problem. To complicate matters, different people solve the same problem in different ways. For example, one person looks at a web conferencing tool as a mechanism for having impromptu meetings with clients. Another person sees it was a vehicle for delivering recording, both live and recorded. Different corporate trainers might want to keep a permanent archive of recorded sessions on a web page, while another might want it on a file share. The reasons behind these varying approaches might be perfectly valid: the web page advocate might want to track downloads, for example. Or, the differences might be matters of taste.
Collaboration tools are, by necessity, extremely plastic. They have to embrace a variety of use cases, including ones that the software designers might never have anticipated.
Since you can't be everything to everyone, you're going to have to pick your targets. Colleague Rob Koplowitz cites four reasons why the collaboration market is hot (innovation, efficiency, re-usable IP, and risk management/compliance). Pick one as a starting point for your product roadmap. It will keep you busy for a long, long time. If you unintentionally cover another solution area, lucky you.
Collaboration may be an extreme case of this "choose or die" maxim, given its universal appeal and vast range of use cases. The same principle applies to every kind of technology, collaboration or something else: You're designing a tool for people unlike yourself. Don't assume that the use case in your organization works anywhere else.