As of May I have moved on from Microsoft. I spent about 18 months there after the acquisition of Parlano (October 2007).
As of May I have moved on from Microsoft. I spent about 18 months there after the acquisition of Parlano (October 2007).
One of my colleagues recently pointed me to Groundswell, a blog about social networking. Today I read a post about a corporate business model for web 2.0. As people who read my (infrequent) posts on this blog know, I have long been skeptical about the long-term business model and usefulness of Facebook. I liked how the above post asked how Facebook, Twitter and others will ultimately monetize their massive networks. I agree with the author that they likely will; I'm just not sure I buy into the value completely.
But maybe that's because I'm old-school and I like to find value where there's real money changing hands. So the concept of a corporate business model for Web 2.0 is intriguing. Many of the companies listed are ones that we are all familiar with, such as Avenue A / Razorfish and salesforce.com. But the one I really like is Jive Software. These guys get the concept of collaborations and the value of communities in this space. What's great about Jive is that they get the value of the group in collaboration, which is something that (surprisingly) not all enterprise software vendors understand.
Yesterday I came across Orgoo, a new integrated communications application. It's interesting because it integrates email, video chat, IM, and Group Chat. In Group Chat, they support both text based chat rooms and then Video Chats for up to 4 people. There are several other applications that do elements of this, such as the ones mentioned in the above post (Yahoo Live, Meebo, ooVoo, Tokbox). But as far as I know this is the first application that brings together all of the above capabilities and can be run entirely in a browser. The private beta is full but apparently Orgoo will be opening up for new invites in the near future.
Social networking is a hot topic these days. Over the past several months I have made a personal goal to figure out how the various social networking tools can be valuable both in my personal live as well as my professional life.
For me, Facebook was an obvious place to start as I have received the most invitations to join Facebook or view other people's information in Facebook. So I joined and uploaded some information about myself. Then I started receiving super pokes and all kinds of other gimmicks from Facebook friends. I can see how this is a fun tool and a great way to keep in touch with friends and family as I can upload pictures of vacations and post status about what I am up to.
However, I am struggling to figure out how this is valuable in my professional life, especially inside a company. For developing my career and networking, it seems like Linked In is a lot more valuable. Either way, there are certain things I would like to publish on Facebook that I would not like my work colleagues to see. For example, pictures of my family hanging out in bathing suits in our last family vacation. No problem on the family seeing this, but probably not the guy down the hall at work.
Inside the company, I have heard stories about companies as large as GE who are heavy users of Facebook and rely on it to get their work done. I don't get it. Are they using it to share documents? Or maybe this is a simple way to publish project information and status? Aren't wikis and blogs a better way to accomplish this?
Am I missing something?
The news hit the wires today – Microsoft is buying Parlano. Whoo hoo!!
It is great to see such validation for the product that so many people have contributed to over the years, including the super-smart team of developers that originally took Parlano out of UBS Warburg and the amazing team of people that we have on staff today. Needless to say, Parlano would never have reached this point without the help of so many talented people. Now it's exciting to think about how much bigger the product will become as we integrate it under the Microsoft Unified Communications umbrella.
At Parlano we have always thought that Persistent Group Chat, and MindAlign in particular, is a perfect way to combine groups of people around topic-based conversations, and then to use these conversations to launch into other modes of communication. While a partner of Microsoft's, we have been working toward this goal for years. Now with this announcement we will be able to put this integration into overdrive.
Thanks to everyone at Parlano past and present. Also, thanks to the great teams of people that we have worked with at Microsoft over the years.
There has been a lot written in the past week about IBM's announcements during VoiceCon and the additions IBM is putting into Sametime 8. Many of these are targeted actions to compete more effectively with Microsoft in the Unified Communications space. IBM's recent announcements include support, via Siemens, to integrate with existing PBX systems, IBM's acquisition of WebDialogs, and IBM's expansion of SameTime to include Persistent Chat.
In a recent Information Week article, it is stated that IBM's approach is different than Microsoft's because IBM's solution allows companies to leverage their existing PBX systems while Microsoft's solution requires companies to rip and replace.
When reading the above article and press releases, a few things come to mind:
First, the Information Week article does not consider Microsoft's VOIP as you are campaign, which is built around integrating with existing PBX systems. Whether or not you believe this is a Trojan horse strategy, Microsoft clearly has a short-term solution for integrating with existing PBX systems, whether they are from Cisco, Nortel, Avaya, etc. This is a good thing since Office Communications Server, while it can act as a standalone PBX, is not yet ready to handle very large organizations.
Second, the Information Week article points to the Microsoft vs. IBM battle for Unified Communications, and points out that IBM's goal with Sametime 8 is to get out ahead of Microsoft (or stay ahead according to IBM's Rhodin). One feature that is highlighted is the screen sharing capability that will be available in Sametime 8's Advanced Version. This is mentioned as a way to get ahead of Microsoft despite Microsoft having application and screen sharing in its product (from the Placeware acquisition) for years (first in LCS 2005 and then again in OCS 2007).
All of these points however are not nearly as interesting as the lack of mention of Cisco. Cisco is investing heavily in the Unified Communications space and I have often wondered how the relationship between Cisco and IBM is faring given rumors that IBM wanted to buy Webex but that Cisco bought it out from underneath them.
Either way, it strikes me that the Unified Communications race is by no means a two horse race. Furthermore, as a veteran of producing Persistent Group Chat products for Unified Communications and Real-Time messaging solutions, I am excited to see Persistent Chat mentioned as one of the key components, along with voice and live meetings, in the race to win the Unified Communications desktop.
Day 4 of Tech Ed marks the end of the expo floor. We have been here all week demo'ing Persistent Chat (MindAlign) running on Microsoft Office Communications Server with integrated video. The turnout has been fantastic and needless to say, everyone has walked away with a lot of excitement about what we are doing in this space.
Some general notes that were especially interesting or exciting:
Speaking of video integration, hats off to the MindAlign 2007 dev team and to Parlano IT . It was only about 1 ½ months ago when we decided to demo video integration at Tech Ed. I can't say it went off without a hitch, but once we got it up and running it looked fantastic.
Now it's off to Universal, or not, depending on the rain…
I was asked today how I would compare Wikis, Blogs, and Persistent Chat. Then, once that comparison was done, throw SharePoint into the mix. In the end, the ultimate question was, if someone has SharePoint, which in v2007 includes Wikis and Blogs, then why would they need Persistent Chat?
My first answer to the question was simple: conversations in the workplace exist with the purpose of achieving an outcome. The outcome is typically an artifact of some kind, where the artifact can be a document, a proposal, a set of milestones, an action plan, etc. In historical terms, these conversations always took place in person or on the phone. With the addition of Unified Communications solutions, we are now able to add video, video conferencing, live meetings, etc. to the mix of conversations. But in the end, the goals don't change: someone needs to get something done and therefore they need to converse in order to achieve this goal. So, the conversation is something real-time, like IM or Persistent Chat, whereas the artifact is something that is published, like a Blog or Wiki entry.
Simply put, there is conversational of collaboration and there is document-based collaboration. Conversational collaboration comes in the form of person-to-person conversations, voice (telephony, VOIP), and video conversations, in addition to text-based conversations in the form of email, IM, and Persistent Chat. Document-based collaboration includes Blogs, Wikis, Intranets, and Document Management systems. Conversational collaboration is useful for arriving at ideas and conclusions. Document based collaboration is useful for documenting those ideas and conclusions.
Another way to classify these collaboration tools is to consider the following graph:
On one axis (Y) collaboration tools can be classified by how dynamic they are. On the other axis (X) they can be classified by the level of persistence within the solution. Below is how I would classify these collaboration solutions:
Person-to-person, voice, and video are all the most dynamic forms of collaboration, but they inherently have no persistence as there is typically no record of the conversation. IM is slightly less dynamic since people generally type slower than they talk, however IM conversations are usually not persistent.
Intranets are extremely persistent but most of their content is very static and does not frequently change. I have argued in previous blog posts that the static nature of Intranets is one of the primary reasons why the Intranet model is generally being phased out in favor of other more dynamic forms of collaboration.
Documents are more persistent since you can PDF a document and keep the contents forever. However they are also slightly more collaborative as you can exchange documents and mark edits, comments, etc. within those documents. Anyone who has been involved in a contracting process with lawyers knows what this process looks like (it is painful).
Wikis and Blogs are tough to classify in comparison to each other. However I think it is easy to say that Wikis and Blogs are more dynamic than documents even though they may or may not be as persistent as documents. On one hand Blogs are very persistent because people typically do not modify their posts after the fact. On the other hand they are not very persistent because Blog entries are typically not organized by anything other than author and old entries scroll off the page and are lost in time. Blogs are collaborative only because people can comment on posts. But this concept of commenting on posts is nowhere near as real-time and dynamic as IM, Persistent Chat, or Voice/Video. In some regard Blogs can be compared to Email since an inbox is usually one un-organized stream of incoming emails. Blogs are typically one un-organized stream-of-conscience from a particular person.
Wikis on the other hand are very dynamic since many people can change the text of an article. But in the end Wikis are typically just a shared document, where the documents are organized around topics. Someone can publish information on a topic and others can edit that content. Wikipedia is the best example of this. It is an encyclopedia that everyone edits and therefore arguably has the best content. While this is a great place to document ideas, it is not a very fluent and dynamic way to have a conversation.
Persistent Chat is as dynamic as IM since you communicate in the same was as you do in IM. Arguably it may be slightly more dynamic since it is easier to share files in Persistent Chat rooms than it is in IM (many IM solutions do not support file transfer). But Persistent Chat combines the real-time nature of IM, persistent nature of Blogs, and the topic-based nature of Wikis. So you can go to a room/channel that is based on a topic, search through archives of what was said on that topic, and then participate in the conversation of that topic in real-time. If the team in the room/channel comes to a conclusion and/or artifact, that artifact can be published to a nWiki or Blog. But in many cases it is as important to understand how you came to the decision as it is to knowing what the decision was.
Ultimately, someone might ask: If I have Blogs, Wikis, and IM, why do I need Persistent Chat? My answer would be that after reading this article the only way to have a conversation with me about it is to post a comment. Yet that is only useful for a small number of comments. An IM conversation would be better, but what if we wanted to add a 3rd party to that conversation? And what if that 3rd party wanted to be able to search through everything that was said before they joined the conversation? That is a concept that is only available through Persistent Chat.
I read a great article in the Wall Street Journal today written by Andrew Blackman about Intranets. The title of the article was "Dated and Confused" which in my opinion is a perfect description of the corporate intranet.
The article discusses several points about corporate intranets and then notes how wikis and blogs are being used solve traditional intranet problems. For smaller startup-up companies like Parlano, where I work, wikis and intranets are the same thing. We use our internal wiki as well as Sharepoint to store documentation and information for our company. Having used an internal wiki for several years I can say that the problems of intranets have only partially been solved by wikis.
The problem areas can be divided into a few categories.
First is the problem of input, or getting the information into the intranet. Several people in the WSJ article were quoted as saying that the information they needed simply was not available on their intranet because the people who had that information did not post it; instead the information was "in someone's head, or on a drive somewhere I didn't have access to". Everyone who has experience using any type of corporate intranet or blog has had the same experience. You have information to share, but you are either not sure where to put it or you don't know how to format it properly. You try to figure it out but then you run out of time and the thought or information is forever stuck in the depths of your mind.
We use two wikis – one is a basic open-source wiki and another is twiki. Both make it much easier to publish information although you are still required to learn the formatting tricks. In our first wiki it was nearly impossible to upload a file. You could do it, however it required uploading the file to a share and then manually formatting the url so people could link to the file. You want document versioning with that? Forget it. The second version allows for file versioning and is somewhat similar to our SharePoint implementation. So there are improvements. But still, what if you don't know where to put the information?
The second major problem is getting the information out of the intranet in order to use it. While the age-old problem is organization and finding the information you want (one company in the article recently had 212,000 pages on their intranet!), this is lately being solved by sophisticated search. The problem of the intranet is the same one I have on my hard drive: I can't remember where I put stuff and therefore I need a good desktop search. If you have a good search on your intranet or wiki then organization should not be your problem.
However, I still find it difficult to get files from an intranet site, a good wiki, or even SharePoint. Part of this comes from me being a software developer by trade and being used to a good source code repository. The other part comes from me now being in management and needing to access information from my laptop while on a plane. With a good source code tool you can, with one click of a button, synchronize all of your data and download anything that is out-of-date to your pc. That way when you are disconnected you can still access everything. When you reconnect your changes are automatically sync'ed into the repository. It drives me crazy that our intranet solutions don't do this and therefore I have to manually check timestamps of documents when I can't remember whether I edited it since it was checked out. Hopefully SharePoint 2007 has solved this problem and I just don't know it yet. Or maybe I have to wait for further Groove integration.
With all of that said, the real problem is the concept of dynamic vs. static information on an intranet site. The WSJ article addresses this and refers to Social Networking aspects of Microsoft's and IBM's latest products. I particularly like the "social distance" concept in SharePoint 2007, where searches return not only documents, but also people knowledgeable in the search, where the people are listed in order of how well you know them.
In the end, however, an intranet site is created to address a topic. And as David Gootzit from Gartner said, "The value of any network is dependent on participation, on the numbers involved". But if the site is related to a topic, then where is the topic-based conversation in the search results? And, if the success of the site is dependent on the participation, where is the metaphor for facilitating real-time collaboration around that topic (rather than amongst individuals)?
We have often discussed how Persistent Chat, which is a real-time, topic-based conversation between people, can turn the model of an intranet upside down. It can do so by creating a dynamic, real-time communication environment where people always start their days in order to communicate with others around their topics of interest. Yet the conversations in these "channels", or rooms, ultimately lead to exchanges of documents, tasks that need to be assigned, or artifacts that need to be logged. While much of the discussion around this, and even the decisions, can be found in the "backchat", or history of the chat conversations, a Wiki page or intranet site dedicated to that topic is the perfect complement to such a conversation.
Intranets have been around for years and companies have spent millions, if not billions of dollars funding designs and redesigns of their corporate intranets. While it still remains to be seen, I am willing to be that none of these redesigns will work until real-time communications, such as Persistent Chat, are added into these historically static collaboration environments.
I had the pleasure to meet with a customer this week whose primary objective over the next year is to increase their ability to serve their customers. In this customer's market, services are quickly becoming commoditized and margins are being squeezed. Therefore, the only way to maintain their margins and their premium relationships with their customers is to integrate themselves more fully with the customer's business and build a world class organization of coordinated people to service the customer.
I am sure that this customer's problem is not unique. The same statement, about commoditization of products and squeezed margins, could probably be said about several industries. But the answer, or at least this solution (there may be many approaches) seems to be consistent. Knowing your customer is always going to help you build better products for that customer. And providing a more cohesive and coordinated front to that customer will always lead to them wanting to utilize more services from your business.
Due to the last decade of M & A activity, many organizations have become large in order to offer a vast, diversified set of products to customers. But many of these organizations are quickly feeling the pains of the customer I mentioned above. This pain is that there is always a relationship or account manager that will interact regularly with the customer. However at some point the account manager will need to delegate customer requests to people within the organization who provide the products. Yet in many organizations these various product teams were built inorganically, and therefore they are not sitting right next to each other. The result is a lack of coordination on the customer's behalf across product lines. Furthermore, it is nearly impossible for the account manager to constantly stay on top of requests for the customer.
In this particular use case, our customer will solve this problem through better collaboration. The idea is that more people within the organization should know intimate details about the customer, and that each product team should coordinate their efforts in order to better service the customer. For some, collaboration comes in many forms. For example, collaboration may utilize portals and indexed data. But the key problem with using these solutions alone is that data must first be created in a place where it can be indexed. This requires people to end their conference calls and/or meetings and then write up notes or action items for other people to see. In many cases this does not happen.
This is where we have seen Persistent Group Chat make a huge difference. While Persistent Chat is not a workflow tool for managing discrete actions, it is the perfect solution for capturing the dialog between teams. The reason it works so well is that the teams communicate within the same tool that is also logging the content and information. As a result, there is no need to retrospectively write meeting notes or action items. The conversation is instantly logged and others on the team can read the archives at any time (assuming they have the correct permissions).
In the use case of the account manager, they can share persistent chat rooms with the product teams and discuss requests specific to the customer. In the communication with the customer, the account manager will have better knowledge and provide better answers. In cases where the customer needs to interact with a team, this interaction can also take place in Persistent Chat rooms (we call them channels). Not only will the customer have the impression that they are being serviced by an army of people, but the dialog will be automatically persisted so that both sides of the conversation can read through archives when necessary.
This is the type of simple solution that can be employed to improve customer service and ultimately allow companies to maintain their competitive edge and margins.