SharePoint, Meet Yammer; Is It Time For Microsoft To Burn The Boats?

In collaboration, there are cloud vendors, on-premises vendors and hybrid vendors. Here's the thing; hybrid vendors are not really cloud vendors. What do I mean by that? Let's look at two different applications that both run as part of Office 365; SharePoint and Yammer. SharePoint is hybrid (Microsoft will happily allow you to choose between an on-prem or cloud) and Yammer is pure cloud. In many respects they are similar; both run in Microsoft run data centers, can be purchased on a subscription basis, are fast and easy to provision, provide automated upgrades, put reliability and security in the hands of the vendor, etc. Lots to like about running an application in the cloud. 

Here's where they are not alike. A pure cloud vendor is fundamentally better positioned to gather requirements and deliver new functionality faster. Let's take a look at a new release process might work with a product based on a traditional product software develop approach, like SharePoint:

  • A business planning cycle determines new requirements that are critical to market success
  • A product planning cycle determines which features and functions are technically and economically feasible to build within the development cycle
  • Engineering builds a new release of the product
  • The product code goes through multiple release stages to get market feedback and test the stability of the new features and functions 
  • The product becomes GA (generally available) 
  • Rinse and repeat

This process can take a while. If we think about SharePoint releases (2001, 2003, 2007, 2010, 2013) it's about three years. Now, if you have a cloud version you can release incremental functionality into the cloud on a more regular basis but substantial improvement are generally tied to major releases. Ultimately you can only manage so many versions of software and can't be too out of sync with your on-premises users. So, the on-premises version essentially becomes an anchor that drags on how quickly you can introduce significant new functionality. So, even if the vendor is closely and accurately following market trends to guide the product, users may have to wait several years to get the cool new stuff. And the dynamic can work the other way as well. Once a new feature is added users will likely have to live with it for three years. A real stinker can take up valuable screen real estate for a long time even though no one wants it there. 

Let's take a look at how the process might work with a pure cloud approach to development, as practiced by Microsoft's latest acquisition, Yammer:

  • Build and introduce new feature or functionality
  • Evaluate user reaction to the new feature by releasing it to a controlled subset of users
  • If users like it, keep it, if not, pull it

This process can execute over the period of weeks or months and there is only one code base to worry about, since it all runs from vendor controlled data centers. The end result is a better opportunity for the vendor to gauge the value of new features and functionality based on real-world production environment feedback and a delivery model that allows that new functionality to get into the product fast. 

None of this is anything new. So, why bring it up now? In our latest SharePoint adoption survey we discovered that while IT remains satisfied with SharePoint, satisfaction among business users softened from the previous year. When asked why they were dissatisfied responses included "We're not seeing the level of adoption we expected" - 54%; "Users don't like the SharePoint experience"- 51%; "Users prefer other tools, such as email" - 41%. 

All of this indicates an opportunity to provide a better experience and newly acquired Yammer offers a model to do just that. So, if you're Microsoft, do you begin to make bigger and bigger bets on Yammer? Do you make it the core of your social strategy going forward? Do you extend more and more core SharePoint functionality through the agile Yammer interaction layer? Sounds good, right? 

Here's the rub. While all of this sounds great, it means Microsoft would take a dependency on some key functionality that would be available only in the cloud. As in, "You can't have anything in the cloud ever? Oh, then you can't have this cool new stuff". Microsoft has used the catch-phrase "All in" to describe their commitment to the cloud. Up to now, they have not been all the way "all in". "All in" means being willing to turn your back on some portion of your addressable market to take full advantage of the benefits described above. It means burning the boats so there is no way back, only forward. And this is a conversation that is likely taking place right now because business and product planning for the next version of SharePoint must be well underway. 

The data above is sited above is only a small part of the overall survey that fed a new document from John Rymer and myself. While I took the opportunity to use the data to tee up a provocative subject, the document is really focused on some key findings including:

  • SharePoint is still a favorite among IT with 81% running the 2010 version and 68% planning to upgrade to 2013 within two years
  • Only 8% plan a full deployment in the Office 365 cloud, but an additional 26% will move to a hybrid cloud, on-premises deployment 
  • 91% do not yet have a SharePoint mobility strategy in place

Forrester clients can access the full report here:

SharePoint Enters Its Awkward Teenage Years

Comments

Faster != Better

Rob,

Faster deployment cycles don't mean that you are improving quality or delivering additional value. Every point vendor touts this as an advantage; then, when they grow up, they realize that their platform has become so large that they can't be as agile as they once were. As a vendor of a cloud-based product, I can tell you from personal experience that the development cycle is the same - you still have to gather requirements, define features, code and test them before you can release. The bigger you get the harder that becomes, especially when you factor in multiple language support and regional restrictions/regulations/requirements.

It's taken years for Microsoft to get Office 365 to market. They will have to rip apart most of the SharePoint backend to "Yammer" it as you propose. Think of how long that will take. And if they did, how agile do you think the final product would be, considering everything that SharePoint does which Yammer does not?

Furthermore, there's no indication that this is actually what users want. The issues you describe in the responses to your survey don't suggest that Yammer is the solution. Are you certain it would improve adoption? Replace email? Give users the experience they want? Remember, when you have a hammer you tend to see everything as a nail - but relentlessly pounding on screws won't get you very far.

At some point Microsoft will have to decide how to satisfy both customer segments as the core of SharePoint adopters will never move entirely to any type of public cloud. The trick is to figure out how to do both and still be responsive to changes in the marketplace. And deal with the type of customer satisfaction issues that your survey revealed at the same time (which are nothing new - users have been saying the same thing about collaboration tools of all types for years). Using some elements of Yammer to address those issues may be a part of the answer but it certainly isn't the entire solution - just look at how many of your respondents expressed a high degree of satisfaction with the current product. That's significant - careful thought is required before making drastic changes that alienate your core customer base.