065. SharePoint: Office Builds Our Own Server

I admit up front this will be one of my favorite sections to offer. SharePoint was a remarkable point in the history of Office as we expanded the product line from desktop Win32 applications to include servers, a prelude to services. Within Microsoft this was by many accounts not only heretical, but also impossible. How could a team made up of “UI programmers” develop a server? Strategically, the inherent conflict between a server tuned for information workers and the actual server business was intense and fraught with difficulties. I would learn another lesson in bundling versus stand-alone product, and endless lessons in just how much the analyst world struggled to make sense of Microsoft’s product line, even when it just didn’t matter.

While I could spend many pages on the features and my love of SharePoint as a product, the transition Microsoft was going through while we developed SharePoint is equally important to the overall story being told. We will start there.

Back to 064. The Start of Office v. NetDocs

“We need an ‘Office’ server” was another one of those driveway lunchroom conversations with SteveB before he became CEO. It was a concrete expression of an abstraction. What he was really saying was that Office needed to think broadly about how to solve the problems information workers were having. That business card he used to make a note of “find me all the stuff about France” was now looking like a product issue for Office. We were all-in on the opportunity and were well ahead of Steve, having been thinking about this from the moment we saw FrontPage. We made it through the 97 and 2000 product cycles and FrontPage had established itself as a favorite tool of Internet Service Providers. We were ready to build on that foundation and expand the little web server we had been using to share product documents on the team. An Office server was a key part of the Office10 vision. The path from vision to RTM was not going to be a straight line.

The first half of the year 2000 was nothing short of eventful:

* Microsoft and customers survived the looming Y2K apocalypse. Despite dystopian fears, except for a few trivial and humorous problems, nothing went wrong at midnight.

* Windows 2000 shipped.

* Microsoft rose to an astronomical $500 billion market cap.

* Then the NASDAQ dropped more than 2,000 points with the Dot Com Bubble becoming a defining event of the rise of the internet.

* Judge Jackson declared Microsoft a monopoly that violated the Sherman Act (causing a 15 percent post-bubble stock price drop), and then later ordered the split of Microsoft.

* Office was attacked by a massive virus, resulting in the disabling of core product features.

* Capping this off, Forum 2000 was a landmark event in the evolution of Windows Server and introduction of what would become Hailstorm in an effort to rebuild Microsoft as an innovator in the internet era.

* PaulMa retired from Microsoft after having had an incredible influence on the company’s operating systems, platforms, and enterprise transformation.

It was also the start of SteveB’s tenure as CEO. Many believed this would mean little or no change given how SteveB was known widely as the “third founder.” SteveB would lead sales and marketing leadership and overall company execution. BillG would lead on technology vision and strategy. This seemed a formalization of what we always felt was the case. On the other hand, how could someone so different keep doing things the same way?

Earlier in the Spring of 1999, there was a BusinessWeek cover story about the remaking of Microsoft. It featured a photo of Bill and Steve together and the subheading “While Bill Gates plots strategy. . .Steve Ballmer shakes up the culture.”

With so much going on, Steve’s first reorganization as CEO seemed relatively minor even expected given how the sales force he created reorganized almost yearly. It didn’t seem like much of a “remaking of Microsoft” as the headlines touted months ago. There were some new people, but the big changes were in financial reporting.

Jeff Raikes (JeffR) returned to Office in the role of group vice president of the soon-to-be-renamed Productivity and Business Services (PBS) division. It was noteworthy that the name included services as per the end of 1999 strategy mail from BillG. JeffR was among the most tenured executives and led the original “Office” organization, the Office Business Unit, OBU, home to Word and Mail. Jeff joined Microsoft in 1981 when the company was 100 or so people, recruited from Apple by SteveB for a product role in Apps, where he led marketing for the original wave of Macintosh applications (and also shared a house with Steve for several months). On his PocketPC he used to keep a “days at Microsoft” Pocket Excel sheet he would open up when talking about how long he’d been at the company. Jeff was frequently mistaken for BillG, as both sported the requisite Microsoft uniform of loafers, khakis, and collared shirts, but it was the ’80s plastic-rimmed glasses that sealed the deal. He grew up in Nebraska, often describing his beloved family farm, an aerial photo of which hung in his office. Before Apple, Jeff attended Stanford. Jeff was the earliest of advocates of pen and tablet computing, leading those as part of Microsoft’s first foray into what was then called Windows for Pen Computing, which was also my first booth duty demonstration using C++ to code for a pen. Jeff also wrote an early memo describing the scenario that would become Excel pivot tables.

Prior to leading PBS, JeffR was the leader of the global sales force, having taken over for SteveB upon his transition to president. He pioneered the mid-year sales review process, which became a staple of the fiscal year planning process with its all-day meetings held through the entire month of January, all around the world. Among the sales team, Jeff was a legendary leader and stood shoulder-to-shoulder with SteveB in the evolution of sales at the company.

With his success in the field, Jeff was more a product of the SteveB perspective on problems and solutions owing to his most recent experience scaling the enterprise field sales organization. As Bill’s longtime friend, he was probably the only executive that was equally well-versed in both BillG and SteveB.

Jeff brought with him a team of support personnel. There was even a chief of staff, a role standard in the field but foreign to the product groups. This was hard to escape notice as we had quite a few offices and a big conference room taken offline (reserved) when in 2004 we eventually moved into the new building 36 that we had fought hard to occupy. Part of assembling the staff ended up taking a good chunk of the top floor of Building 36, which was designed to maximize space for the team, including window offices and already maxed out with the dev team. Space was always the subject of intramural skirmishes.

As part of the staffing of the PBS organization, for the first time, the Office group had substantial and dedicated finance and HR teams front and center of the organization—a seat at JeffR’s leadership team meeting. Some little things that were normal in the field seemed awkward or at least different in the product groups—like routine emails drafted by a staff member to be sent by Jeff for various planning or process tasks or scheduling meetings months in advance. JeffR scheduled everything, so spontaneous chats or walking by the office to talk became less the norm. Instead of PeteH stopping by my office, CollJ (our executive assistant) would get an email from JeffR’s assistant “Can you make sure your exec is available for . . . ”

It was natural though not necessarily mature of me to be skeptical of seemingly trivial changes, but these took place in the larger context of SteveB changes. I was not sure the new processes were consistent with a product-development team culture that was casual, ad hoc, and direct, but perhaps that was the point. During the transition I recalled a story that a former SteveB field staffer told me after he moved to Office marketing. He described how when SteveB moved from the Windows HQ product group to lead Sales, SteveB shifted his hardcore perspective on budget accountability. He changed to believe the field should be responsible for marketing dollars rather than the headquarters (product) group that needed additional discipline, a complete reversal from his days in HQ. As SteveB changed perspective, the problem area moved too. I started to feel we were a problem and Jeff’s role was to fix something. I wasn’t sure what or who was the problem.

Almost right away, JeffR pushed us to better equip the field to sell a big vision for the future of knowledge workers. This had been a long simmering tension point around Office, where I always felt squeezed between making sure we did not cause problems with customers timing Enterprise Agreement (EA) sales and customers wanting to know the future so they might sign up for an Enterprise Agreement. There was always that looming problem of future releases sounding so exciting, customers would choose to wait. Office was under a lot of pressure to get customers to deploy the current version and not wait. It seemed logical then talking about the future would only slow down deployment. This was clearly something that needed to be fixed. In fact, there were echoes of the SteveB 100 one-on-one meetings where he pushed me on this topic. Overall products were still late to market, and we’d just put ourselves out there massively with the expectations set by Forum 2000.

What the field wanted were more materials like Forum 2000, not better demos and whitepapers about Office 2000. The new head of Office marketing explained to me “when I used to work at IBM, we sold more products today based on slide decks about the future, then on any demonstrations of what today’s products actually did.”

I still admit I have a difficult time with that logic, but I am grown up enough now to know it is the reality of enterprise selling. I was uncomfortable selling the future. I was forever hung up on making promises we could not keep, or at least were not sure we could keep. I also felt selling the future was fraught with opportunities for misunderstanding. I’ve seen customers extrapolate features in directions we’d never go. It is obvious in hindsight I was just an engineer and naïve to the ways of sales. I was stuck feeling too high integrity to sell. I was silly.

There was one exception. We found a way to craft our own version of the future that was so far removed from product specifics, that it could not be mistaken for future product versus a futuristic vision.

To show customers (and JeffR) what Office was going to be like, we created a whole experience, almost a Disney-esque Future World of Productivity. MikeAng (now leading product planning) and the design team set up an Office of the Future. The team literally built an entire onsite immersive experience called the Center for Information Work. It occupied several large rooms (2600 sq ft) in a space next door to the Executive Briefing Center. Inspired by the soon-to-be blockbuster film Minority Report starring Tom Cruise (dystopian vision aside), the CIW offered guests a giant wall projecting status of the business—metrics for manufacturing, orders, and more. By a careful combination of scripting and clicking of wireless remotes, the demo revealed wall-size status reports, alerts, problems, and resolutions.

The CIW had a mock-up of an airplane cabin, long before there was Wi-Fi. There was a car of the future, where work and important decision-making continued en route, something that was just starting to take hold with wireless headsets, BlackBerry phones, and PDAs. Mike had listened to me go on and on about my new Toyota Prius hybrid and how futuristic it felt with an oddly mounted gear shift and big touch screen, so he secured a Prius dashboard and front seat, making the auto portion of the exhibit forward-thinking (and for me, super cool). Mike briefly regretted humoring me when SteveB’s main account, Ford, showed up and gave us grief over the car choice.

There were several workstations at the CIW with a wraparound, curved, 180-degree-view display, with the screens partitioned for monitoring activities, work, and collaboration. Curved displays weren’t available to buy but, working with display manufacturers, a curved perspective was created by stitching together flat screens with no bezels—innovative at the time.

The centerpiece was a Microsoft Research project called RingCam developed by Anoop Gupta’s team (AnoopG, who was also a BillG technical assistant), which was a combination of hardware and software for conducting remote meetings, in 2000! The camera sat in the middle of the table seamlessly capturing the audio and video of all attendees. It featured a fancy array microphone that combined with software to detect the speaker and switch the video image to them. At each chair in the conference room there was a Wi-Fi-connected Tablet PC. The PC was an integrated part of the demonstration—documents were signed, spreadsheets were examined, and notes were taken on this device of the future. As if to emphasize the permanence and paramount importance of tablets, the conference room table featured integrated, angled stands for the tablets designed for hands-free viewing and notetaking.

For the first time, I felt like we had an opportunity to get ahead of the constant demand for the future of Office. We revealed no dates, no specific features, but successfully put forth a vision for the seamless use of technology to enhance collaboration, improve decision-making, and integrate data into daily work.

Over the next months, CIW became a meeting place for CEOs, heads of state, VIPs, press, and customers considering Enterprise Agreements visiting Microsoft. Soon there was a team that ran tours nonstop. Over 1000 customers per month made their way through the exhibit.

We found success for the field by creating a story about what we might build one day presented like a World’s Fair exhibit that in no way could be confused with a product roadmap or plans.

JeffR’s new leadership team embarked on its first group project—to identify areas for growth in the business (the business was growing high double digits, but we were forever paranoid about peaking and the bottom falling out). JeffR and the new finance and business development team engaged a major consulting firm to develop a market map for the whole of the business productivity space. Where was all the money on business software going? This project became known as the opportunity map as we crafted a vision for PBS—not a vision like Office or CIW but a plan for determining what new categories of software to enter or serve.

Outside of Microsoft broad horizontal tools like word processing and spreadsheets, the software industry was in an expansion phase driven by the rise of server computing and the web. Businesses were building out data centers and adding server-based applications for sales, marketing, finance, human resources, and more. These tools were domain-specific capabilities that often featured integration with Office, particularly Outlook and Excel, and were generally much more expensive per user than Office, though used by fewer people. The opportunity map was designed to capture the amount of revenue flowing to the rest of the productivity software space.

The map, unsurprisingly, looked as much like a set of opportunities as it did like a set of all the tools that integrated with Office or all the tools that weren’t Office. Categories like Customer Relationship Management (CRM) were highly dependent on using email and integrating with Outlook as the user interface. Business intelligence for finance analyzed vast amounts of transactional data from SAP, or Oracle products to be sliced and diced in Excel, even if they worked to provide analysis in a web browser. While the market need existed to solve these product areas and scenarios, we always struggled with bringing to market domain-focused products while also running the risk of competing with partners who were telling their customers to buy Office.

The question arose as to how we would sell any new products. Would we add new dedicated salespeople for new products, bundle those products with the existing EA, or just add features to Office? We could add features to Office, but charging more for them rather than leveraging those features to drive EA renewal and upgrades was something we faced many times. The pull of bundling more and more into the core value proposition was relentless and the path of least resistance. Even creating an upsell SKU by holding back specific features was a battle against just making sure the customer renewed their EA. Equally difficult was marshaling a new field sales process should we have an entirely new product to sell. Everything was a tradeoff against either finding new EAs or ensuring renewals. I had run into this buzzsaw before and was skeptical, even with Jeff’s command of the field, that we would be able to find ways to sell whole new products.

It also didn’t help that most of these market map businesses relied heavily on consulting and professional services, something Microsoft steadfastly avoided. BillG was not a fan of consulting just as he long disliked product support or anything that could scale by only adding more people. As we kept learning, most of the integration with Office was less about the strengths of Office and more about trying to be part of the sales momentum and ubiquity of Office—using Microsoft’s distribution channel potentially afforded by Office. The makers of these tools did not necessarily want more software integration from Microsoft. Rather they wanted to find a way to insert their products into the massive Microsoft sales engine. If this sounds at all familiar, it is the dynamic we hear today time and again from SaaS companies.

Document Management was a market map opportunity that served customers such as law firms and pharmaceutical companies producing huge numbers of documents, requiring a detailed history of changes to those documents. Customers were always clamoring for a solution from Microsoft in the hopes it would be cheaper, or even free with Office. The existing market was a typical domain-specific product with high prices, low volume, requiring consulting or value-added resellers.

Aiming to enter this market while also broadening or redefining it, a server product under development in a different organization since 1998, Tahoe, planned to cater to the new space of knowledge management, a growing category of software for white-collar workers. The capabilities planned for the first version included managing a company’s Office documents, collaboration, versioning, profiling, and security. These features were to compete with products used in document-heavy professions such as legal and research. Tahoe was also going to be a server for an intranet that supported professional content management tools, web search (like Yahoo but for your own information), and more. Tahoe was going to do quite a bit, perhaps too much. Jeff Teper (JeffTe) led Tahoe and this new product team.

Tahoe, a codename, was a good example of a product arguably designed from the field sales organization out. As an example, at one tumultuous presentation to sales leaders I attended, Steve was anxious backstage to deliver a message to the field that Redmond had heard his calls for an Office server. The work we had done with Office Server Extensions and FrontPage in Office 2000 was not enough. We needed a product for the new generation of Chief Knowledge Officers (a new job big companies were creating) to compete with Lotus/IBM Notes (now called Domino). He knew of the Tahoe plans, but it didn’t seem like enough. There were existing plans for other products with codenames (Grizzly, Polar) and even a side project known as “Digital Dashboard”. In a classic reaction, he was saying we needed more, and sooner.

In what I can only remember as a blur of a tension-filled few moments, all the roadmaps for those products were realigned with components moved from one to another. It was confusing and I had only the vaguest idea of what would get produced. I just knew deciding backstage at a sales meeting probably would not stick. There was a confusing clarification issued after the meeting which remains difficult to parse. I struggled quite a bit because I knew we were in the space with code, dates, and a plan for Office10, but it lacked a certain strategic glow that the other products had. Our execution focused plan could not compete with big visions to dominate an entire ambiguous category of knowledge management. We just wanted to help people share and collaborate with Office. Our products were simple and, effectively, non-strategic.

That glow was that the new product relied on and connected our entire server product line: Windows Server, Active Directory, Exchange (including the new release codenamed Platinum), and SQL Server. What the field and strategic people loved was that the knowledge management from Microsoft used (or required) all the servers too. Such strategic connections were great for efficiency of sales resources and messaging. The whole package could be bundled up as knowledge management and the sales process focused on that high-level message, and not product-focused messages across five different areas. This approach spoke to CIOs and their strategy, not to line executives and execution. In a sense, this approach solved for knowledge management by creating another bundle, but not one designed and built together.

That such a product would be next to impossible to deliver and almost certainly fail to work well, was unfortunately a secondary concern.

In parallel with Tahoe (and the other products), the Office server we were building for Office10 had already survived a tumultuous run-up to get to solid plans. We based the project on FrontPage and the solid market foundation we had built. To handle key scenarios, we needed an additional place to store data beyond standard Windows file servers. For example, customers might want to label a document for marketing and another for sales and then quickly sort or select documents for only one category. The obvious solution to this was SQL but we were organizationally much closer to Exchange, the mail server, especially because of Outlook. Selling Exchange was slightly more important than selling SQL, owing to the battle with IBM/Lotus and the long-term advantage we would gain from an Exchange win.

We spent months going around in circles trying to make Exchange work. At one point I had a showdown with the development manager leading the incubation, MikeKo (an original Excel developer working in the FrontPage team), who was dead set against using Exchange. He would have known, because he was also the original development manager on Outlook. I couldn’t even get him to experiment with Exchange, which left me to defend our non-use of Exchange to the various executives involved. It was part of my job but not pleasant. Of course, I knew he was right, and I was trying to at least bring data to our decision. He thought I was foolish for even considering pushing Exchange on him.

The innovation underpinning our server product was a simple database, a list. Everything was going to be a list. There were lists of people, lists of dates, lists of announcements, lists of documents, lists of comments about documents, even a survey/poll feature for developing custom questionnaires to use, and more. Each list had all the same capabilities in that lists could be customized with different columns, sorted, filtered, and in general treated just like one would treat a list in Excel (or the Access database) while doing all of this from the comfort of Internet Explorer or Netscape Navigator.

We also had features being developed separately to publish office documents to a web server and maintain discussions about them, receive email notice when documents changed or were added (today we call these notifications), and more.

Though we started off with multiple teams, we reconciled the different approaches and arrived at one single plan. We called the product OWS, for Office Web Server (no exciting code name). We were deeply concerned about cost and complexity to deploy it, so we also made sure it worked with the free version of SQL, thus maintaining the free distribution of the Office Server Extensions from Office9. Backed by a full server and the full version of SQL, the product could support hundreds of users (including the entire Office team) but was easy and lightweight enough that groups of 5-10 could easily use it.

OWS was incredibly simple, yet wildly powerful. Even today in researching this section, I ran “SETUPSE.EXE” from the Office XP (“Office10”) CDROM on a standard Windows XP computer. With just a few clicks I had a full team web site up and running. Playing around with the resulting product brought waves of great feelings for all that we had built. Office built a server, a really good one.

Much of this simplicity obscures a remarkable program management effort in addition to the engineering work to build OWS. Program management started in the FrontPage team where JulieLar led the creation and incubation of the original efforts. In order to achieve the breadth of features and tight integration with Office, she partnered with another team in Office (the Office Product Unit) that delivered on integration with applications (for example opening and saving files to OWS) and other features already planned by them—this team was led by Richard Wolf (RWolf), an original champion of the concepts behind an Office server going back to the FrontPage acquisition. The connections across the team also included features built in Word, Excel, and PowerPoint. Creating such a highly collaborative PM environment to deliver integrated products was a hallmark of the new Office team, and OWS exemplified the work.

The full set of features would fill a whole other post. The full set of features would fill a whole other post. Even during pre-release press briefings, we would show up with a single laptop to show off a server at a time when server demos required multiple hefty computers. Many demos started in the server and flowed to Word and Excel then back to the browser. The excitement was such for the product that we ended up (through no small effort) connecting Word, Excel, PowerPoint, and Outlook to the server in a variety of novel ways—no one had really connected desktop productivity tools to a web server. When it came to mail, document authoring, presentations, and spreadsheets—the core of business productivity—those desktop files were like islands the internet could not reach. To the readers that wonder why we did not finish the job and do everything in the browser, I would note were still more than 7 years before Google would acquire its first web-based editing tool (Writely) and the Office team starting the web browser versions of Word, Excel, and PowerPoint. The web browser was not yet up to the task.

Apologies for a bit of indulgence by including the following list. Marketing’s final product guide for the release listed four pages of features including:

* Team Web Site

* Lists with sorting, filtering, custom views, notifications via email, import from Excel, and support column types including single line of text, multiple line of text, numbers, currency, date/time, multiple choice, checkbox Yes/No, internet link, picture, and the ability to choose from an item in a separate list

* Announcements

* Events including Outlook integration

* Contacts including Outlook integration

* Tasks

* Links

* Surveys

* Discussion Boards

* Document and Web Page Discussions (discussions within Office documents or about any web page)

* Document Libraries

* Save/Open dialog integration with Office

* Search using Windows web server built-in Search

* Full customization with the new FrontPage

OWS worked easily through a web interface. It even worked with Netscape Navigator, which drove a lot of Microsoft people kind of crazy.

Below is a demonstration I put together. It is running on a Windows XP Dell Latitude laptop from the same era (with typical specs). Everything was installed using the DVD that shipped with Office XP Special Edition (Office + FrontPage). Keep in mind this is state of the art HTML user experience from 1999-2000.

There was a big problem though, particularly with the document library feature. OWS and Tahoe overlapped quite a bit. Where Tahoe targeted IT managers with enterprise infrastructure, Office10’s OWS targeted teams and individuals, though required IT to set up a server and deploy it.

While Tahoe was progressing through its development cycle, Office10 was finishing up. We began deploying OWS to teams and the feedback was incredibly positive. We knew we were on to something.

Despite being asked to, there was no way to reconcile the strategic overlap. Office10’s server was small, lightweight, and had few requirements. It was designed like an Office product in that it implemented a focused set of features, simply. Tahoe was big, had significant infrastructure requirements, and required a lot of work to set up, customize, and integrate with the rest of the infrastructure. It was complex and not particularly suited to end-users. That was exactly perfect for what the field wanted—a big investment to get something working and integration with all the other servers they were selling seemed far more strategic than Office’s previously free server download.

During a one-on-one with BillG he really let me know how he felt. The meeting was set up to push me to reconcile the Exchange versus SQL storage debate. As CSA, Bill’s most critical project was achieving what he called “storage unification” across our products. He wanted to get everyone to use a single data storage engine, eventually called WinFS (a story for another section). In the meantime, deliberately shipping collaboration that did not fully utilize one storage system was a high crime. In the heat of this discussion, Bill said that it wasn’t that OWS lacked strategy, but rather it was “anti-strategic”. It was as if OWS was a net negative for what we were trying to accomplish.

Ugh.

The more we talked things through, the more we found an opportunity—and by opportunity, I mean opportunity for me to avoid a drawn-out battle between conflicting products that created nothing more than grief and a lot of meetings and no happy customers. The more we found an opportunity to avoid simply shutting down a project for lack of strategy and leaving us exposed in the market for what (at least I believed to be) an enormous space in web-based collaboration for regular information workers. The most useful parts of Tahoe, from my perspective, were the ability to search across a company’s disparate information sources, and to manage published intranet content sites and dashboards. We could thread a needle between otherwise overlapping products.

At the market map offsite, having had several heated email exchanges prior, Tahoe and Office (JeffTe and I) crafted a strategy, a napkin strategy—literally. Every company should deploy Office10 OWS for any team to use. All IT needed to do was set up a small server or two, and people in a company could create a team site—inside a company someone could visit a web server and, in a few clicks, have a custom team site up and running in a self-service manner. We started using this internally and it was instantly a hit, so much so, Microsoft IT became worried about the proliferation of all these sites. Just a year or so after shipping, we had over 3,000 SharePoint Team sites inside of Microsoft.

Enter Tahoe.

Every company could buy Tahoe and use it as the portal to all the OWS team sites that would proliferate around a company. The Portal category was gaining steam and came to represent the implementation of knowledge management. The more OWS sites a company created, the more valuable Tahoe became in order to search across them, keep a directory of them, and so on. For huge companies, Tahoe had other capabilities such as published sites for the company with news, information, the ability to search other important corporate information, even emails stored in Exchange, and an architecture to build corporate dashboards that were all the rage with IT. We navigated our way to a strategy of freemium with an enterprise upsell, like so many products in today’s SaaS era. Looked at another way, we created a classic enterprise arsonist-firefighter strategy whereby we at once distribute a free product that proliferates and another product, a revenue positive one, to manage that proliferation.

The SharePoint name, created and secured by the Tahoe team, proved easy to use for both Tahoe, now SharePoint Portal Server (SPS), and SharePoint Team Services (STS), formerly OWS. SPS provided synergy with the server strategy and hot features like dashboards that CIOs wanted. STS provided the departmental and end-user appeal where work happened. I thought this naming to be particularly clever—SPS and STS. I was horribly wrong and when combined with the full name was unwieldy (Microsoft SharePoint Portal Server 2001 and Microsoft SharePoint Team Services, where legally we could not use SPS and STS). This was a classic example of Microsoft product naming. My apologies.

We agreed that SPS would ship at the same time as Office10 as well, which was exceedingly important. Throughout the release we worked to have a unified experience to the degree we could. SharePoint would become a symbol of JeffR’s new organization and the broader value of Office products to corporate customers.

SPS was a perfect product for an era of complex server products. The industry was blossoming with products from companies such as SAP, Siebel, Cognos, and more. Microsoft spent tens of millions of dollars and hundreds of person-years, including consultants, to roll out SAP. The same with Siebel. Such heavyweight products were state of the art in enterprise software. SPS embraced and reflected those attributes.

STS was an emotional product for me. It was the end of a journey that started with making a web page with our specifications for Office9 and using FrontPage running on a server under my desk. The FrontPage team enhanced the server extensions to create the foundation for STS. The product was pulled in many directions for strategic reasons, but we stuck to it. More than once, I had to go to meetings where we debated killing STS because it conflicted with some strategy (Windows Server, Exchange, bCentral, etc.).

The idea of Office extended by a website for each Office user and team was incredibly important simply because it made using Office better. It was also a vision we had from the time we acquired FrontPage—everyone should have their own place on the web where it is easy to keep their work and share it with others. We were clearly too early. As we will see it was not just that the world was not ready, the world was anti-ready. SPS fit with the products of the era that remained top-down, complex, and under the full control of IT.

We struggled to turn what we built into an asset—the company, or mostly the field, thought of Office as the desktop EA. Getting the right skills to communicate and sell a server was not part of the Office sales motion. It was frustrating to watch companies introduce products that did the things we did and receive credit with analysts and press, or even customers asking if they should use them. We were inundated with requests to do business partnerships with team collaboration products all while, essentially, building a good one in relative silence.

The expression my former managed ChrisP used was “magic beans.” It was a way of describing how some people in the company, no matter what they were doing, seemed to be able to summon magic beans and make products look much larger than life. There was something about STS that lacked magic beans.

We had big plans for STS down the road in the next release. STS was the foundation for extending Office to subscriptions and software as a service.

STS was not without controversy on its own. The company had not yet warmed up to web pages, especially as user experience. I realize how crazy this must sound. In 2000, the company was still of the view that the web is the type of experience for “reach” and the “rich” experience is what happened on the desktop. BillG especially was still hoping for a Win32-like experience for everything we did that used the internet. As an example, the discussions feature of STS also worked from directly inside the applications. It was a ridiculous amount of work we took on just to reinforce this view. Other features such as a Tasks list and Contacts List, which were simply trivial lists in STS, were viewed harshly by BillG because those were supposed to be in Exchange and Outlook (we also did the work so they could be accessed from Outlook).

During the traditional demos with the team, Bill got to see SharePoint (SPS and STS) of course as it was a pillar of the release. We left that section of the demo with him grumbling to me in person, “I hate that UI”. Years went by with him saying “SharePoint? That thing I hate.” Every time someone mentioned SharePoint or sent him a link to a SharePoint document (oh, the links did have horrible URLs that were crazy long and meaningless) he would grumble if I was there or forward me the mail complaining about the link or the UI. I concluded this was much more about the idea of a commoditized HTML-based interface than any specific choices for STS, that even today are fairly benign.

Regretfully, STS was oddly lost in the shuffle. CIOs and thus our field were far more excited by the prospects of enterprise-wide dashboards and other SPS scenarios. The team collaboration was almost backburnered. Where SharePoint really made a name was with an army of consultants who saw SPS as a big opportunity for value-added reselling. The fancy web interface for digital dashboards was both slick and required custom programming for every customer. Combine that with the purchase and management of server hardware and there was a great business for consultants. JeffTe and the new SPS marketing team started a SharePoint conference which turned out to be a cornerstone event for the PBS organization and the field loved everything SharePoint.

Internally during the beta of Office10 we worked with Microsoft IT and created a self-service STS. With a single click, any person in the company could create their own STS site. IT would manage it, back up the data, and keep it all running. It was an enormous hit. Every time a team had a project or an event they would create and STS site. Teams that were already managing their own internal web sites with custom hardware and web development were switching. STS was a huge win for IT, who had a new product they could offer their internal Microsoft customers. We had hoped to replicate this at every big customer. Why not? The rollout of SPS, while exciting to MSIT, did not go as smoothly. The search capabilities were slow, limited, and frustrating to use. The dashboards were difficult to create and slow. It would take some time to transition content publishing sites to the SPS model. The high-end document management features did not replace the domain solutions in place. It was tough.

Even as we came close to shipping, all was not so great. Sometimes it can be difficult to really understand success and what was actually achieved.

Around the internet today, Google Drive, Box, and Dropbox are all products in which I see STS (not literally of course). There are a dozen start-ups building products today with the features like those STS had in 2000, even using the “everything is a list” metaphor such as Notion. The foundation of STS remains a key part of Office 365 today, but still more than likely underutilized by customers given the rise of so many viable alternatives or even the difficulty of finding SharePoint capabilities. Of course, a great many people and organizations rely on modern SharePoint as a key place for storing documents and files. As BillG used to say in exasperated moments, “yet another place to put files.” The potential for tools to improve team collaboration beyond file sharing was mostly obscured by the complexity and weight of the whole offering.

Being early is sometimes the same as being wrong. Being in a bundle is sometimes…not being at all.

A bit after launching the whole wave of products, at the annual sales mid-year reviews SteveB was pushing one country on their Office numbers. As I recall, the country manager began to complain that they pushed SharePoint, but it wasn’t landing. The manager said they are doing a bang-up business and the channel (those value-added resellers) and CIOs love SharePoint, but customers aren’t using the product. I froze. I knew for sure I was about to get pounced on by SteveB in front of everyone. Instead, Steve looked at the me then the room, and agreed. He said, “I get it, no one anywhere is using SharePoint.” Others in the room disputed that, perhaps out of concern for leaving a bad impression for the SharePoint brand they loved.

The conversation continued and Steve turned to me and mouthed again “no one is using it”.

He knew. He was right. As popular as the product was, the part we were selling and what led the conferences, the excitement from industry analysts, and reseller activity, just wasn’t what people were using inside of companies. The team collaboration parts of the product, STS, didn’t receive the attention or visibility so those were under-utilized as well. Was the product a failure?

No, the business results were clear. SharePoint all up had succeeded competitively and by expanding the overall push of servers into the enterprise. This wasn’t the only time customers were buying what we used to call shelfware. The Office business benefitted enormously from the upsell of Office Standard to Office Professional. Office Pro added the Access database, another wonderful product with an incredibly fierce and loyal following. The only problem was that it was used by a single-digit percentage of users, even though half and soon nearly all customers purchased it. We didn’t intend for that to be. It was a win, but bittersweet. It can also confuse what success is in a big company.

Microsoft had a talent for creating a success out of a product that still wasn’t quite a success, as if through sheer force of will and the power of distribution. We issued momentum press releases citing statistics in the millions. A single major company logo deploys a mission critical application which we reference relentlessly. We can even garner support of resellers around the world who will gladly take the business we send to them, even if the result is simply a showcase application. SharePoint was even touted as the fastest product to one billion dollars in revenue, which given Microsoft’s revenue mechanisms is an awkward datapoint. These were the tools of the era. Today, the techniques of growth hacking are the norm such as user-interface that triggers use of a feature that may or may not be intended, or defaults that drive apparent usage of features. All of these are used with bundled products, because absent the specifics of customers directly acquiring a product, Microsoft had no genuine indication of market success. The nature of the big enterprise bundle makes knowing reality difficult.

What really matters is if people are using the product naturally (organically) and the usage is improving (not necessarily more, but decidedly more valuable). We lacked the tools in the early 2000s to really know, but SteveB’s intuition was never doubted. Today we think of this as lacking a clear understanding of product-market fit, a state of existence when the market literally pulls the product out of the company.

We did have exciting moments with STS to be sure. We had an inbound support incident from Japan where a customer was hitting limits for how many documents could be added to a single folder. We had not tested it with more than thousands and learned the customer was unable to add over 100,000 documents while converting all their file servers to SharePoint. Yikes.

The lesson of the bundling things together (STS bundled with SPS, SPS effectively bundled with Exchange and SQL) should have been clear to me by now, having lost the battle over Outlook and soon some other products. I should have admitted defeat and recognized that new things go in the existing product bundle and the economics always make sense—meaning that not charging more doesn’t matter because customers continue to value what they paid for already. We just really dislike building shelfware. Winning with shelfware doesn’t feel like winning.

Every time we were deficient competitively it was to an unbundled product. Even our own unbundled businesses of Visio and Project were almost one billion dollars. Even worse, the unwieldy size and scope of the Office bundle all but guaranteed most customers would never know or experience most of what we do. That’s the fate of most every successful bundle in business software from Microsoft, Oracle, Adobe, SAP, and more. Any success, or defeat of a competitor, comes from an overwhelming mass of software. I was simply naïve to think customers don’t appreciate free, which after all is the same as adding more to the bundle means. I eventually came to think about this as customers paying $300/year for Word, Excel, PowerPoint, and Outlook and everything else was just free and of little ascribed value. The very reason new or startup competitors can win is because there is a price attached so customers know about a product.

With a bundle as features are added and customers keep buying, the value of the bundle appears to be reinforced. The act of bundling is correlated with growth, but there’s no causal link. Conversely, when something is not bundled but the entirety of the sales motion is with the bundle, then the company concludes the unbundled product was a failure on its merits. Again, that is only a correlation not a causation. The presence of growth hacking and so-called vanity metrics distort available metrics, causing even more clouded judgements. Bundles make for great value and efficient sales engine but make it extremely difficult to know if you’re doing the right thing or building a good product. Bundles make it easy to be lazy when it comes to building a fantastic product. Bundled products don’t have to be great to win, just good enough.

I once vented to BillG about this, and his view was more sanguine. He said to think of the whole as a portfolio and to just make sure each release that the total value was what it needed to be. Bill was big on the portfolio approach to management.

In a similar conversation, SteveB was also right about the fact that sometimes the bundle wins, even with an inferior product, because the winning product is not just a product but the value of the product, distribution, and ecosystem around it.

The product confusion did not end. The Windows Server team that sold file sharing servers was deeply concerned they were being pushed out by STS, which did provide a much better way to share files. After many rounds of discussion, the best course to solve this strategy problem was to include STS in Windows as well. More distribution is better I thought. Due to antitrust scrutiny of any bundling choices, we ended up renaming STS to WSS, calling it Windows SharePoint Services. What seemed very clever only further served to marginalize or fracture the product.

This was killing me. I could not figure out what was going wrong or what I was doing wrong. It seemed to be so hard to get traction bringing this to market. I know not everyone shared my view of how cool STS was. What was cool was being measured differently. It was like we valued momentum or strategy more than usage. It couldn’t be that building more complex products that were harder to use and more difficult to deploy and manage was the right answer?

At times I wondered if I personally lacked magic beans, but I didn’t obsess about it. I was able to guide large products, lead teams where people were generally happy (as measured by the ever-present MS Poll survey on employee satisfaction, which SteveB re-emphasized significantly), and to get done what was promised without much dirt flying. None of my managers ever commented on the innovative work the team accomplished—things like SharePoint—or the risks we took, like how we shifted the team to build Office, or even the Office Assistant (“Failure is good,” BillG said often). Rather, the conversation was always thanking me for keeping the trains running on time. Yes, it was great Office shipped on time when almost nothing else did, but it was so much more. The team deserved credit for more than just good at shipping.

My mentor Jeff Harbers and I were once talking and he offered me a way to think about this. Leonard Nimoy’s autobiography, I Am Not Spock, detailed all the things he did besides that one role—that one role everyone knew about. Many thought he begrudged Spock and was not appreciative of the role like fans were. I felt as though shipping was cool, but the team, and I, were so much more. A decade after his original book was published, Nimoy wrote I Am Spock, in which he embraced the role as part of him and explained how people misunderstood the first book. Later Jeff Raikes even lifted my Spock analogy in one of my performance reviews. It resonated. I reached peace thinking about that duality.

Later, working on Windows, I completely embraced it.

On to 066. Killing a Killer Feature (In Outlook, Again)

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit hardcoresoftware.learningbyshipping.com