If I Built Facebook At Work: Part Two – All about the use case.

In my last blog post, I talked about who I think of as the users and key decision makers for a business service provided by Facebook. The Facebook At Work that I’m imagining needs both end users and business stakeholders getting value from it to be successful. So now we need to talk about use cases – what should Facebook At Work actually do?

I think Facebook should not try to recreate a full enterprise social solution with Facebook At Work.  When you think about a social platform, typically you start from a social graph – a set of connections between people. This shows up as followers or friends or something similar in all these products. I think Facebook is best off skipping this. As we dive into the use cases below, I don’t think this is necessary. 

Also, I don’t think Facebook needs to build every feature that can be in enterprise platform. In particular, I don’t think Facebook At Work needs all of the content creation kinds of tools (blog, wiki, discussion) that exist in these platforms. This is both because those tools often already exist in companies (I’ll talk more about this in the third blog post) and because the more the Facebook At Work platform becomes about composing business content, the more likely it will run into all the complexities of enterprise content. How is security maintained? Can it be found in enterprise search? And so on.

So what use cases should Facebook At Work tackle for the end user? I think I would start with very simple use cases. 
 

  1. Share and view key updates relevant to work quickly and easily
  2. Ask a question
  3. Simple and easy discussion around documents (including with external parties)
 

Yeah, I would start with probably only three use cases for the end user. In all three cases, however, there’s an important capability that needs to be included – smart integration with the consumer Facebook service.

Sharing and viewing updates is pretty much just like you expect with posting to a regular Facebook stream and viewing your news feed. The key parts here are that Facebook has invested a lot in good sharing controls and in algorithmic sorting of news feed posts. I think Facebook should be able to work off of its existing algorithms and decide who sees what posts with very little data gathered from users (i.e., users won’t need to choose to follow or friend other users). With just a little effort of collecting who reports to whom, Facebook could tune this algorithm a lot for the enterprise.

The integration I foresee with the consumer service is the option to link your identities (your consumer Facebook account and your Facebook At Work account). With this in place, a user should be able to do things like share into the Facebook At Work stream from their consumer Facebook account.
 

Asking a question isn’t really much different than sharing. The reason social networks are good for this use case is that you may not know who knows the answer to a question. So the only key things here are getting the question to the right person, making sure the question gets answered, and closing out the question. Interestingly, Facebook experimented with specific question functionality at one point. I don’t know what happened to it, but I think the use case is quite powerful.

Again, the interesting story here is linking to the consumer side. Perhaps you have a question that you want to ask both internally and externally. Or maybe you see a question from someone else internally, and you think your external network would have a good answer. Note that some companies will get really scared about the security questions here even though nothing prevents a person from copying a question from a company email into the current Facebook service today. I’ll talk about this more in my third blog post.

The reason to have a document use case is that documents are a central part of work for most people.  In many companies today, work on documents still happens via email. This is especially true when external parties are involved. This use case is more or less the entire value proposition for some companies. I think Facebook is in a position to tackle this use case and do a good job across both web and mobile interfaces. Like the other use cases, being able to bring in people to look at a document based on their consumer Facebook identities is a nice value.
 

I think the core use cases for the company champion should be tie to specific business problems.  The top use cases I would include would be:
 

  1. Internal communications
  2. Amplifying messaging
  3. Find expertise
  4. Find business contacts
  5. Analytics
 

 

Again, it’s a pretty short list. Much more could be added, but I think starting with a few well-implemented and clear value propositions is the strongest way to launch.

Internal communications makes the list because you’re already creating a destination for people to view, share, and react to business-relevant information. Letting communications people post messages to this stream gives them a powerful capability beyond email and publishing on their intranet.  And some good analytics will tell them how well their messaging is working.

I see the amplify feature as just a button on some posts. If a user clicks it, she sends that post out to her personal Facebook stream. The underlying business stories here are things like the marketing team sharing a new product announcement or a job posting. Clearly not every user will just rebroadcast the company message (and being able to edit what you amplify will be important), but this can be big win.

Finding expertise is about searching both within the company network, but also in the attached personal networks. Finding people who know certain things is one of the toughest problems in big companies.  Facebook has invested a lot in search, so this feels like a natural extension.

Finding business contacts is a sales use case that’s similar to finding experts. Frequently, a sales person will want to know if anyone has a contact at ABC Company. This often results in an email and then people searching in LinkedIn. With a feature pre-built for this, the search could automatically span linked personal Facebook networks. Again, you need features here to make it easy to ask the internal person to broker a connection, but the data is the key to making the use case work.

Lastly, all good enterprise products have reporting. With social computing in companies, one of the common questions is “how do I know we’re getting business value from this?” Since the use cases listed here are pretty tightly tied to business stories, all you really need are some decent reports to show that the answer is yes.

So the big picture here is that we want to satisfy both end users and business stakeholders. We want end users to have some direct value, but we also want to have someone who wins inside the company because some business function works better. Having stakeholders who are invested in the success of a product is key to any enterprise product being adopted. In my next post, I’ll chat about why I think these use cases would be adopted over the alternatives if I built Facebook At Work.

Subscribe

We love social, and we love our blog. Stay informed with the latest Sitrion news and announcements by subscribing to our blog.

RSS 
Brian Kellner, Chief Technology Officer

Brian Kellner is responsible for Sitrion's product strategy and development. Brian has held product or development management positions for over a dozen years. Most recently he was Vice President of Enterprise Products for Webroot Software. Brian holds a B.S. in Aerospace Engineering from the Massachusetts Institute of Technology and an M.S. in Management from Colorado Tech.

The next generation workplace

Lead the way with our solutions built to empower your employees.

Learn more

Get in contact

Are you looking for support help? Do you have questions about our products and solutions? We’re happy to help.

Contact us

 

Or call 1-877-SITRION
Share this page
X
Tell your colleagues and friends about Sitrion. Choose a social channel below to share this page.