Tag Archives: innovation

Enterprise Social Software and Portals: A Brief Comparison of Deployment Patterns

In my last post, I examined whether or not Enterprise Social Software (ESS) is the functional equivalent of enterprise portal applications as they existed ten years ago. My conclusion was:

From a functional perspective, ESS is quite similar to enterprise portal software in the way that it presents information, but that does not tell the whole story. ESS lacks critical personalization capabilities, but provides better collaboration, process, publication and distribution, categorization, and integration functionality than portals. In my judgment, ESS is somewhat similar to portal software, but mainly in appearance. It makes more functionality available than portals did, but needs to add a key missing piece – personalization.

In this post, I will focus on the observation that ESS resembles enterprise portals in another regard – how and why it is deployed.

Enterprise v. Smaller Deployments

Portals were initially marketed as a tool for enterprise-wide communication and interaction, with each internal or external user role having its own personalized set of resources available in the user interface. While there were some early enterprise-wide deployments, portal software was deployed far more often at the functional level to support specific business processes (e.g. sales, procurement, and research portals) or at the departmental level to support operations.

Enterprise social software has also been touted as most valuable when deployed across an organization. However, like portal software, ESS has most often been deployed at the functional level in support of activities such as marketing, customer service, and competitive intelligence. As a result, the promised network effects of enterprise-wide deployments have not been realized to-date, just as they were not with most portal deployments.

Internal- v. External-Facing Deployments

Most early portal deployments were internally-focused, as shown in this InformationWeek summary of market research conducted in 2001. Not only was there a smaller number of externally-focused deployments, mixed-audience deployments did not begin to appear until the portal market was extremely mature. ESS deployments have followed this same pattern, and we are just now seeing early efforts to blend inward- and outward-facing business activity in common ESS environments.

Internal Use Cases

Portal software was often deployed in response to a specific business need. Among the most common were:

  • intranet replacement/updgrade
  • self-service HR
  • application aggregation
  • document/content management
  • expertise location
  • knowledge sharing
  • executive dashboards

ESS has been deployed for many of the same reasons, especially intranet replacement, application aggregation, expertise location, and knowledge sharing.

External Use Cases

Portal software was deployed externally to provide self-service access to corporate information. In some cases, access to selected application functionality was also provided to key business partners. Retail and B2B portals enabled customers to purchase goods and services online. Process acceleration, revenue growth, and cost reduction were the key business drivers behind nearly all external portal uses.

ESS doesn’t seem to have the same goals. I have seen some, but little, evidence that external communities are being leveraged to accelerate business processes or reduce costs. Peer support communities are a good example of cost reduction via ESS. The goal of most outward-facing ESS deployments seems to be customer engagement that translates (eventually) into increased innovation and revenue for the deploying organization.


ESS deployments today strongly resemble portal projects that were undertaken ten years ago. Few, if any, ESS deployments have been enterprise-wide. Instead, ESS is deployed to many of the same department and functional groups, to support the same business processes, and to drive many of the same business results as portals were a decade ago (and still are.)

What does this commonality with early portal deployments mean for ESS? I will examine that in my next post. Until then, I would love to hear your reaction to what I have presented here.

Have Software Suppliers Become Too Customer-Focused?

Remember the old dictum that says “the customer is always right”? Guess what, they aren’t.

Many times during my career as a management consultant, I have heard clients articulate their business needs and wants in the form of technical solution requirements. Besides completely ignoring the important intermediary step of stating those needs and wants as business requirements, the technical requirements voiced too often reflect only what the client knows to be possible; they do not imagine new and alternative technical solutions to business challenges. In other words, customers are not always a great source for innovative ideas on software functionality, much less on entirely new products.

I mention this because, lately, I have been hearing so many software vendors saying how focused they are on use cases and requirements voiced by their customers. Platform module and individual application development seems to be highly driven by customer feedback these days. Perhaps too highly.

Please do not misunderstand; software suppliers should consult frequently with customers, absorb their feedback, and develop against their use cases and requirements. However, vendors must also proactively imagine and build new functionality that will help customers overcome real and critical business challenges in ways that that they did not realize were possible.

A few software suppliers are mindful of this need. I recently saw a position opening announcement for a Senior Product Manager at a software provider that listed the following as one of the key qualifications for a successful candidate:

A demonstrated ability to get past what customers say they want and deliver what they really need

WOW! How powerful is that? It would be difficult to say it in a more simple, clear fashion.

The point of this post is to encourage software providers to think beyond stated customer technical requirements. Those are an important part of product planning, but cannot be the sole basis on which current product development and long-term roadmap decisions are made. Think and act like a management consultant; help your customers envision previously unimagined possibilities. That is a sustainable source of product innovation and competitive advantage.

More on Microblogging: Evolution of the Enterprise Market

Following my post last week on the need for additional filters in enterprise microblogging tools and activity streams, I participated in an interesting Twitter conversation on the subject of microblogging and complexity. The spontaneous conversation began when Greg Lowe, a well-respected Enterprise 2.0 evangelist at Alcatel-Lucent, asked:

“Can stand alone micro-blogging solutions survive when platform plays introduce the feature?”

I immediately replied:

“Yes, if they innovate faster”

Greg shot back:

“is microblogging autonomy about innovation, or simple elegance? More features usually leads to lower usability?”

And, later, he asked a complementary question:

“is there a risk of Microblogging becoming “too complicated”?”

Is Greg on to something here? Do more features usually lead to lower usability? Will functional innovation be the downfall of stand-alone microblogging solutions, or will it help them stay ahead of platform vendors as they incorporate microblogging into their offerings?

One of the commonly heard complaints about software in general, and enterprise software in particular, is that it is too complicated. There are too many features and functions, and how to make use of them is not intuitive. On the other hand, usability is a hallmark of Web 2.0 software, and, if we make it too complex, it is likely that some people will abandon it in favor of simpler tools, whatever those may be.

But that dichotomy does not tell the entire story. Based on anecdotal evidence (there is no published quantitative research available), early adopters of Web 2.0 software in the enterprise appear to value simplicity in software they use. However, as a colleague, Thomas Vander Wal, pointed out to me yesterday, that may not be true for later, mainstream adopters. Ease-of-use may be desirable in microblogging (or any other) software, but having adequate features to enable effective, efficient usage is also necessary to achieve significant adoption. Later adopters need to see that a tool can help them in a significant way before they will begin to use it; marginal utility does not sway them, even if the tool is highly usable.

Simple may not be sustainable. As I wrote last week in this post, as enterprise use of microblogging and activity streams has increased and matured, so has the need for filters. Individuals, workgroups, and communities want to direct micro-messages to specific recipients, and they need to filter their activity streams to increase their ability to make sense out of the raging river of incoming information. Those needs will only increase as more workers microblog and more information sources are integrated into activity streams.

In the public microblogging sphere, Twitter provides a solid example of the need to add functionality to a simple service as adoption grows in terms of registered users and use cases. As more individuals used Twitter, in ways that were never envisioned by its creators, the service responded by adding functionality such as search, re-tweeting, and lists. Each of these features added some degree of complexity to the service, but also improved its usability and value.

In the evolution of any software, there is a trade-off between simplicity and functionality that must be carefully managed. How does one do that? One way is to continuously solicit and accept user feedback. That allows the software provider and organizations deploying it to sense when they are nearing the point where functionality begins to overwhelm ease of use in a harmful manner. Another technique is to roll out new features in small doses at reasonable intervals. Some even advocate slipping new features in unannounced and letting users discover them for themselves. Hosted deployment of software (whether on-premise or off-site) makes this easier to do, since new features are automatically switched on for people using the software.

So back to the original question; can stand-alone microblogging solutions fend off the collaboration suite and platform vendors as they incorporate microblogging and activity streams in their offerings? My definitive answer is “yes”, because there is still room for functionality to be added to microblogging before it becomes over-complicated.

Based on the historical evolution of other software types and categories, it is likely that the smaller vendors, who are  intensely focused on microblogging, will be the innovators, rather than the platform players. As long as vendors of stand-alone microblogging offerings continue to innovate quickly without confusing their customers, they will thrive. That said, a platform vendor could drive microblogging feature innovation if they so desired; think about what IBM has done with its Sametime instant messaging platform. However, I see no evidence of that happening in the microblogging sphere at this time.

The most plausible scenario is that at some point, small, focused vendors driving microblogging innovation (e.g. Socialcast, Yammer) will be acquired by larger vendors, who will integrate the acquired features into their collaboration suite or platform. My sense is that we are still 2-3 years away from that happening, because there is still room for value-producing innovation in microblogging.

What do you think?

Why We Struggle With Social Software ROI

money_bag_with_dollar_signOne of the prominent themes in any discussion of social software in the enterprise is Return on Investment (ROI). I opined in a previous post that all too often ROI is a hurdle put in place by opponents of a project to prevent it from happening or succeeding. I also said that organizations that have collaboration hardwired into their culture understand and accept the value of social software without a demonstration of ROI. Conversely, even a reasonable, positive ROI projection isn’t likely to get a proposed social software project approved in an organization that doesn’t “get” collaboration. I stand by those statements and have another observation to add:

The primary reason organizations are struggling with ROI in social software is because they have little or no idea what they want to accomplish by using it. There’s no link to business strategy and tactics.

To calculate ROI, one must define specific, measurable metrics, for which annual financial benefits can be projected out over 3-5 years. The rub is in developing the metrics. Defining appropriate metrics requires knowing what the organization wants to accomplish by making an investment. We all know this. Yet too many seem to forget this basic principle of ROI when contemplating an initial social software project. They get caught up in the hype of the newest fad and forget that technology must be deployed in support of a well-defined strategic goal or objective. They focus on the “soft” benefits of social software use that are widely communicated today instead of on how using social software in support of a specific business strategy or tactic can lead to revenue increases and cost reductions in the business.

Before you and your organization get too enamored with the shiny new toys presented by social software, or get caught up in the hype cycle, take a step back and ask questions like:

  • What specific strategic imperative(s) could be enabled by social software?
  • Where could social software help us increase revenue and/or reduce operating costs?
  • Why are some of our employees using social software despite our reservations about it?
  • Who might we be able to create new and valuable business relationships with by using social software?
  • What differentiation for our company and it’s offering(s) could be built using social software?
  • How could social software be used to increase trust inside and outside of our organization?

The answers provided by asking these kinds of questions will provide the purpose behind your social software project and investment. Knowing the purpose will make it possible to define metrics that can be quantified in dollars (or whatever currency your organization operates in) and demonstrate potential ROI.

Are you having trouble defining questions that reveal your organization’s purpose for investing in social software? Please contact me so we can discuss ways that I can help.

Beware the Wisdom of Crowds

I couldn’t help but thinking more about this installment of Zippy after seeing it in the Boston Globe on Sunday.  Much has been said lately about the wisdom of crowds and most of it has been positive.  Many companies have begun to look to their customers and business partners for input regarding existing products and services.  Some organizations have taken the next step and solicited ideas for new offerings from external constituents.

Crowdsourcing is a welcome form of collaboration whose positive effects outweigh the potential shortcomings, but Bill Griffith is right to question our rush to embrace the wisdom of crowds in his cartoon strip.  We need to take the limitations of this type of collaboration into account when making business decisions based on information gathered from the crowd.

Like it or not, ignorance plays a role in shaping the feedback generated by the crowd.  Individuals (and the collective, by extension) are often not aware of what is possible.  They can’t imagine an innovative solution because they are unable to think beyond what they currently know and understand.

I’ve encountered this bias many times in my work as a consultant.  When helping clients develop new ways to collaborate, I used to ask them questions like “How would you like to collaborate with X?”, or “What would that look like?”, or “How would that work?  More often than not, my efforts to have the client describe what they wanted were rewarded with silence and/or blank looks!

I eventually learned to show clients a potential answer to the question that I’m asking and have them build off of that.  Putting a use case scenario, an interface mock-up, or a process diagram in front of the customer always elicits a response that I can use to begin to understand what they really want.  This is true if I’m working one-on-one with a client or if I’m conducting a workshop with a group.

Next time you turn to the crowd for ideas, be sure to seed some information with which they can innovate.  Don’t ask them to start with a blank sheet if you want great results.