Social technologies: Standalone Applications Or Features?

During CScape at Cisco Live, one of the more interesting conversations I had started with a simple question: Is social software (and collaboration software in general) a set of standalone applications or features of other business applications? This sprang from a discussion on the future of the collaboration technology business and really speaks to a couple of important developments in the market:

 

1) Collaboration platform vendors incorporating social features into their offerings. Anyone who's followed my research and my blog posts knows this story: Cisco, IBM, Microsoft and Novell (amongst others) have released collaboration tools that include robust Web 2.0 technologies such as social networks, tag clouds and blogs. This has led to a maturing of the messaging of pure-play vendors - going from "we have the best social software" to "this is how we solve a specific business problem."

2) Business applications that power business processes are becoming social. Another recurring theme in my research is corporate interest in (and fear of not having) enterprise 2.0 technology has led business application vendors to jump into the market. As these vendors do so, they are seeking out tools to help them make their applications social. The inclusion of business application vendors, though, has put more pressure on the pure-play vendors to find a niche that will allow them to compete with vendors that have sure footholds in businesses.

 

Facing these market realities, is there really room for standalone social software? Well, let's start with how pure-play vendors are beginning to address this crowded competitive landscape:  Jive Software and Socialtext are working to roll out solutions that are embedded in business processes and tie together business applications. These moves are indicative of a simple truth: It's very hard to change business processes (which are tied into corporate culture) and even more difficult to change the way people work (which is tied into human nature), so why not meet them where they are? So, in some regards, it does seem that the pure-play vendors are seeking to weave their way into business processes (and by extension, business applications) by either being a dashboard for managing these processes (the Jive approach) or in tying together applications with a social layer (the Socialtext approach). Taken together with collaboration platform vendors' and business application vendors' incorporation of social software into their offerings, it would appear that social software needs to either tie into other applications or provide an interface with other applications. I don't totally agree.

When thinking about standalone social software, I start with the delineation between intracompany collaboration and intercompany collaboration. Within the firewall of a business, there are established procedures - and applications to support those procedures - that information workers have been groomed to accept. So, in this context, introducing a standalone collaboration tool that requires a business user to work differently is going to have very limited success because you need to fundamentally change the way people work. However, when you cross the firewall and try to create interactions between companies, those processes - and the applications to support them - aren't necessarily mature (if they exist at all). There aren't many applications that allow for colleagues in different companies to share content, ideas and information while building relationships. And because there is a gap here, this is an area where standalone social software can play an important role. For this to happen, though, we need to be farther down the path with standards and security for these technologies.

In sum, it isn't an either or proposition for social technologies - we need embedded and standalone applications. For product managers and marketers, deciding which way to go is a matter of deciding how you want to serve business interactions - behind or across the firewall. If it's the former, then product managers must understand the job types within verticals they intend to serve: the applications they information workers use, the problems they face, the way they work; and product marketers must understand these job-specific items to create the rationale for an IT department to integrate your social layer. If it's the latter, then product managers and marketers need to acknowledge the problems of crossing the firewall - interoperability, security policies, government regulations - and design to address them.

Comments

"information workers have

"information workers have been groomed to accept"

TJ, let's push on that assumption a bit. Leaving email to the side, since email is its own special case, how many enterprise applications do information workers *love* to use?

You use Siebel, right? If you were given the option of ditching Siebel for the same functionality embedded within your collaboration/social software product with a beautiful UI and intuitive UX how fast would you jump at the chance?

Expense reporting? BI? What enterprise app do you use that you really *love*?

I know people have an aversion to anything new, but with the enterprise application bar so low, I have a hard time believing information workers won't be willing to move.

By the way, love your research. Best analyst at Forrester!

Hey, Oliver. Good hearing

Hey, Oliver. Good hearing from you. To answer your question, there aren't any applications that I use on a regular basis that I *love* to use. That said, I can navigate them fairly well, allowing me to do my job in a reasonably efficient manner. And there, I believe, is the rub: is the flashy new UI and sleak UX really going to help me do my job better than what I currently have? And this gets us to the 9x Problem, which John Gourville described a while back: do information workers want a new way to work, or do they just want their current way of working to be a little bit better? I think to date, the answer has been the latter, which is why we haven't seen massive adoption of collaboration tech in general, and social software in particular.

So, while I get what you're saying about business apps being a pain for information workers, I'm not sure an improved UI in something outside of their normal workflow is going to get them to move in great numbers.

Business goals tied with procedures

Hi TJ! Great post on examining the different approach from enterprise software vendors. I couldn't agree more when you mentioned "deciding which way to go is a matter of deciding how you want to serve business interactions", because I firmly believe that all enterprise managers should examine what are the ultimate goals for their companies, be it generating more leads, producing miracle cancer drug, or connecting professionals in a particular area of interest. Then they should work backwards to examine what are the business procedures, human factors and resources that are essential to carry out those goals.

However, many business procedures are abstract and complex, enterprise managers often have a hard time contextualize them into easily understandable formats that can be absorbed by all parties involved in the software deployment stage: employees, vendors and customers. So my questions is, how do you effectively examine the business procedures and convert them into understandable forms that can be integrated into the enterprise software environment? Thanks!

Good Question

Hi Lucas,

Thanks for taking the time to read and respond to this blog post. To answer your question, I'll refer back to my background as a voice of the customer researchaer at a new product development firm: start with the unmet need. As you mentioned, the mistake is to assume that a worker -- or their manager -- can tell you explicitly what additional tools they need in order to do their job more effectively. Because of this, you need to first have an idea of the class of people (i.e. functional role) whose performance you want to improve and then ask them to walk you through their work day, probing on areas where they stumble. In having the workers explain to you what they do in their words, you can begin to map out -- in aggregate -- what the job of a particular role is and mark where in the job individuals have issues.

In identifying these issues, you discover what the unmet needs of the worker are, and what areas could benefit from an infusion of integrated technologies. To validate these findings, I would suggest ethnographic research -- embedding for a day or two with a sampling of workers to get a visual sense of how they work and where they stumble. With these data, you are now in a position to begin designing to serve the needs of that functional role within the context of their business applications.

I'll sugar-coat nothing: this can be an expensive process. But in this world of commoditized collaboration technology and low end user adoption, breaking through requires vendors to undertake these processes to discover where they can help and how they can differentiate.

I hope this helps.

TJ