071. Resolving NetDocs v. Office

With the announcement of .NET, Microsoft was overflowing with projects, many not yet products, destined to become the next big thing in one area or another. Everything had a “Net” somewhere in the name and everything was in the press or in an enterprise strategy deck. There was plenty of optimism, but collectively the company was well ahead of itself. There was simply too much going on to have a coherent strategy or roadmap, even though BillG was 100% focused on that, having assumed the role of Chief Software Architect. The push-pull of “be more innovative” and “ship real soon” meant that many of these efforts were at the ends of the spectrum of “architecturally suboptimal in order to finish” or “architecturally correct but can’t possibly finish”. The unwinding of projects like this is incredibly painful for everyone involved, especially when what really happened is so different than perceptions.

If you have not seen part 1, check out 064. The Start of Office v. NetDocs

Back to 070. Office.NOT

Hardcore Software is a reader-supported publication. To receive new posts and support the work, consider becoming a free or paid subscriber.

I was still working through the stages of grief over a product getting killed or at least wounded, considering what happened to Office.NET quickly renamed Office11 at the last minute. Karma was about to come back around and bite me for, ostensibly, doing the same. Since Forum 2000 in June, the NetDocs product continued development. The team expanded, absorbing products, and broadening the mission. BrianMac used the same approach and much of the team that created Outlook.

The team was fired up but going in several different directions. Depending on who you asked on the team, NetDocs might be something different. What originally started as a new style of document creation tool, blending aspects of word processing, spreadsheets, and databases, expanded into a full-blown email program to replace Outlook, a photo editor, and even a web browser. It was also using the latest (unfinished) and most strategic technologies. Sensing the excitement over XML, the product also found itself deep in that strategy and brand new code. NetDocs was also using the latest reusable code from Internet Explorer, which was great for the IE platform but also meant it was not exactly what most customers thought about as a browser-based implementation. Along the way, it created some of its own technologies such as the ability to install updates easily over the internet. There was a lot of excitement over a product that does. . .everything. How could there not be?

On paper, this was quite something. During the early days of MS-DOS, these all-in-one products always struck a chord with techies and regular people alike. The idea of using only one tool to get everything done, including email, was insanely appealing. In demos, everyone, especially BillG, got excited. The idea Microsoft could finally crack the all-in-one category with a professional tool would be huge. ChrisP had a name for a design demo that incorporated “all the best of everything in one easy-to-use app.” It was called Uniprog Deluxe. That’s what we came to call this expansive vision. It wasn’t meant to be cynical as much as it was meant to imply an unachievability.

Importantly, NetDocs was also a key part in the nascent strategy to use XML everywhere. XML was being pushed heavily by BillG. Despite being a simple text file format, Bill had let XML take on the role of providing a proprietary advantage to Microsoft in some way. This was a difficult topic to discuss because it conflated several aspects of implementation (such as where the actual intellectual property or code was) and appeared to assign proprietary value to a simple text file. Much of the excitement around XML (and thus NetDocs) was because of the concerns over the now ubiquitous HTML format and lack of proprietary control Microsoft had over a format. In short, XML was the way to regain a proprietary control over an internet technology. Whereas HTML was viewed as a display format, XML was viewed as a structured data format. I had a difficult time with the magic attributed to XML, especially because Office was already invested in HTML. I was holding on to the notion that HTML would remain human-readable at some level, whereas XML was brand new but already super complex (advocates would say it was never meant to be human readable). We planned on a significant amount of XML work, but viewed it as interoperability more than proprietary advantage. For example, Excel would be able to import XML data files such as those from the Securities Exchange Commission or SQL databases.

There was one big problem. And a lot of little ones. The big problem was creating yet another email program—while NetDocs did try to do a lot of things, everything emanated from being an email and scheduling product. Microsoft went through several years of a comical email client strategy that was confusing and frustrating to customers. Email was literally the most important product the company was building and the most important enterprise product. Not only was it the key server product, but it was also the key new Office module. Perhaps that is why we had so many email products in the market and in the works—something important attracts a lot of attention from development teams looking to do important work. In a world where we were just establishing enterprise credibility, having multiple email programs was a disaster, especially when our flagship one wasn’t so well-received, yet.

When something is hot, however, every project converges to that product. So everything had to do email.

We had Outlook, which was struggling to become a great product for Exchange and enterprise email. After the initial release that just made it into Office 97, there was the split and the creation of Outlook 98, which was either a not-so-great Exchange client or a not-so-great internet mail client, but not both. Then for Outlook 2000 and then again with Outlook 2002 (XP) we failed several times at becoming a more reliable Exchange client with a new storage engine. Finally, with Outlook11 we committed to addressing the problems, come hell or high water.

We also had the new browser-based version of mail, which we named Outlook, technically Outlook Web Access, even though the relationship to Outlook was zero when it came to code and only acceptable when it came to user experience and features. The inability to share code and limited capabilities of rendering all of Outlook in 2000 era web browsers caused this divergence and inefficiency. Customers were extremely enthusiastic for the promise of browser-based email with Outlook Web Access.

In 1996, the Windows team released Internet Mail and News, or IMN, which became a much-loved internet mail program. It was part of Windows and Internet Explorer, made by the same team. IMN was plugging along doing great things for the internet when it became clear to our enterprise sales efforts that we could not have a first-rate internet mail and so-so Exchange mail. The solution was—and I’m not making this up—to rename IMN to Outlook Express.

This was a decree that neither the Outlook team nor the Windows team liked, but the theory was that it clarified the products for customers. The IMN team did not want to be tainted with yucky enterprise Outlook, and the Outlook team didn’t want to be confused with free or, for that matter, the internet. Customers called everything Outlook and were, basically, always confused. Product support was confused. Reviewers were confused. Most of all, normal people were confused. It was a silly, self-inflicted mess that continued for more than a decade, except for the reality that in 2001 work on both Outlook Express and Internet Explorer stopped, and and improvements were dependent on the future Windows Longhorn. There were no plans to update either on Windows XP. Those capabilities were going to exist in some new form on Longhorn.

We had Outlook, Outlook Web Access, and Outlook Express. The branding and naming relationship was much deeper than any technical one.

To complete the mail strategy, we also offered Hotmail, the web-based email acquired in 1998. Hotmail was both a mail “client” and a mail “server” in BillG architectural diagrams. MSN mail was trying to converge to Hotmail, but was also building a client-side application to compete with AOL (and thus a client mail experience). Hailstorm was slated to provide (or connect to?) a set of these email experiences, but it used a different protocol.

If you were to try to build a matrix of mail clients and mail servers and which connected to which, you’d have a matrix with many holes. Our strategy was a mess.

Many reporters (and customers) at the time looked at this mess and thought of teams competing and some sort of bloody “there can be only one” battle within Microsoft. From inside, it was not that at all. In fact, by and large the teams did not care what each other did. In its own way, each team thought they would win out in the way they expected and the others simply wouldn’t be relevant to the battle the way they defined it. Outlook Express was certain they would win against Eudora (the leading classic internet email program) or Netscape Communicator, if for no other reason a bunch of people weren’t going to pay for Outlook (not to mention, that Outlook was in no way competitive with Eudora). They were right, and the Outlook team put little energy into competing with Eudora or Outlook Express. MSN was going to win with their own subscribers and be the best (and only) experience for their dial-up customers. Hotmail was going to become advertising supported and win in browser-based email. Outlook proper anchored itself in the corporate market with Office, and made all the money.

There was a competition and that was for people. Recruiting and hiring was a source of conflict. Often when a new group spun up, recruiting kicked into high gear. There were neither rules nor much of an internal system that managed individuals moving between teams. Most moves happened by word of mouth. Teams would routinely bump up against the norms (not formal rules) by implying the potential for promotion or broader responsibility with a move. More often than not an employee would get caught in the middle of one manager recruiting heavily and another manager trying to hold their team together in the short term.

Such staffing skirmishes uniquely impacted Office where the vast majority of our hires came from college (hundreds per year) and we maintained a strong culture of finishing a release that was started. Luring people away from the team mid-cycle was something we deeply frowned upon at a cultural level. New hires with even a partial release of Office could join a team having gone through valuable training and initiation by Office. At release boundaries, Office proved a strong net exporter of people to other teams, renewing our own teams with even more college hires the next year. Since there was no coordination by HR, more than anything it was this cross-recruiting that introduced friction between teams.

If there was drama it was mostly constrained to the boardroom where the complex matrix of what worked with what, and who was using the latest technology were BillG’s main discussions. Most of the time the problems were not anyone’s fault, as much as the teams thought it unnecessary to implement something because their customers didn’t care.

Yet the strategy from the top of Microsoft was to resolve these architectural “impurities” and to strive towards rationalization and consistency. Still, that did not create competing groups as much as a set of groups that all thought the other groups weren’t doing their part to increase synergy. There wasn’t anger, hostility, competition for resources, or anything substantial. Mostly, it was just eye-rolling and exasperation at a lot of meetings followed by long emails over how impossibly difficult some alignment would be technically.

The post-2000 Microsoft (after Windows XP and Office XP, with the arrival of the enterprise business) was a period of extensive meetings around synergy and strategy. At the extreme, groups could spin out of control on their own by signing up for too much synergy and strategy. At another extreme, groups could stay focused on shipping. Leading the former meant receiving high praise and attention internally while failing to deliver or delivering what was perceived as suboptimal. Groups of the latter type shipped and often received poor marks for lacking strategic alignment while developing a reputation for being difficult to work with. The reader is invited to guess which type Office was closely identified with and I came to personify that. Nothing occupied my psyche more than this reality I lived. Shipping is really difficult, even more so at scale. As ChrisP used to say in his “Shipping Software” talk from the early 1990s, it is like everyone comes to work every day to prevent a team from shipping. “Everyone” can be many people in a big company.

Every once in a while, something would get so visible and so tricky that a decision would have to be made and we could not just let some notion of passive-aggressive Darwinism decide.

NetDocs was another mail program, one that would in theory work for both Exchange and internet mail, and maybe even Hotmail, MSN, or new Hailstorm mail. Over the intervening years, since the NetDocs team was formed, Outlook won over corporate America and gained an enormous number of features—very difficult to code features. Everything from handling attachments to scheduling meetings across time zones, shared mail accounts, recurring events, sharing calendars with coworkers, SPAM protection, security, looking up other employees in the corporate address book, plus to-do and task lists, and personal contacts, and still more. Those features were built in Outlook; in fact, many weren’t even available in the web version of Outlook Web Access (thus adding to the complexity of our mail story).

To software architects, the code implementing the semantics and capabilities of the Microsoft email solution was in Outlook running on the desktop, not running on the server. It was architected in a decidedly old-school manner, mostly out of necessity but also because of history. The problem (the big problem) was that there was no way for NetDocs to implement all those features either on its own or by sharing code with Outlook. It would be like trying to use Word’s code for footnotes in PowerPoint, without dragging along all of the Word code. Code doesn’t work that way. Getting all that right in the new NetDocs code base was a long project. Infinitely long. The team knew this, primarily because it was made up of many members of the original Outlook team. They were not worried. Their intent was to introduce NetDocs and add features over time.

There were nearly countless smaller features and implementation details to worry about. Being built on all the latest and greatest technologies from .NET and Internet Explorer was great in theory, but in practice most of those technologies themselves were far from being complete. In a commercial product for hundreds of millions of customers, they expected the product to handle typing in the world’s languages (left to right, right to left, vertical and switching between)—a particular hot-button for Office given how much work we put into this area. They expected it to understand how dates, time zones, and other locale-specific data worked, which was especially important in calendaring, and they expected it to work with accessibility tools for people who needed assistive devices to read the screen or used alternatives to mice and keyboards. Customers wanted the product to work on the hardware they owned with the amount of memory and processor they already had. These “abilities” as we called them were a long list of requirements to just release a product that carried the Office logo. Many of these might make sense to readers today because the operating system, particularly mobile phones, provide this auto-magically by simply using the platform as intended and this is verified in the App Store submission process.

In a series of meetings and demos to BillG, SteveB, JeffR (who managed both NetDocs and Office), and many across the company, it became clear we were heading for something a big company never wants to happen—a decision meeting with consequences. I often referred to a line from the movie Wall Street when Gekko (Michael Douglas) sighs, “Showdowns bore me, Larry. Nobody wins.” It is never a good thing when there are only two options on a substantial decision and a deadline, forcing one side to walk away a winner and another a loser. Management is all about avoiding these situations in the first place. The Microsoft of this era didn’t make choices early, and for good reason—the original Windows project was exactly the kind of thing that could arise if you let ideas flourish. Windows NT was essentially a side project. Windows 98 (98 SE, and Me) took on the role of side project. The whole company was built on what were rebellious side projects.

It is easy to skip this point or to take the point of view that conflicting side projects are a cultural disaster that eats a company from the inside. It is very easy to say that. In practice, projects that might conflict also create optionality. Great CEOs treasure optionality. BillG was one of those. The risk is not having too many options, but too few. The other risk is that all the options being developed converge on products that look too much like what we already have versus new approaches. That is the mistake Microsoft made with some frequency. Too many photo sharing tools. Too many data access technologies. Too many mail clients. Each of which was similar, but different while not anchored in a scenario that introduced a step function change in the trajectory of a category. The key indicators of potential trouble are usually obvious in hindsight. First, the project plans become especially expansive and generally can’t be scaled back because every feature area is critical. Second, the team size becomes especially large. Rarely do small teams cause big problems.

In this case, NetDocs worked super hard and made a ton of progress. Between two alternatives of fully replacing Outlook in the next release of Office or adding a fourth mail program even one that was potentially exciting to Microsoft’s already confused mail strategy, there was no good answer. Not wanting to decide immediately, a question was how much more time it would take to be a full replacement for Outlook. Brian and team wanted to release a product and grow into the market, rather than wait and wait perhaps suffering from the enemy of the good is the perfect syndrome.

Unfortunately, catching up over time seemed like an unbounded problem as well—Outlook and Exchange were evolving. These products were still early in their lifecycles. For example, the major work to improve reliability was about to start and that could have a broad impact on all the code already written for NetDocs. Across Office, everyone was working to integrate with Outlook. In the competition with Lotus Notes, we continued to try many new features to embrace programmability of mail. It was not simply replacing a static view of email but plugging into an entire collaboration strategy. We already failed twice trying to use the new storage system for Outlook, would NetDocs be able to make it work?

The only thing we could do, and have a rational email strategy, was decide not to ship NetDocs and find a way to create a new product that did not try to replace Outlook. That’s what I wanted to do and advocated. The past few years of trying to stabilize Outlook left an impression on me. I didn’t see a path where NetDocs could ever catch up and was deeply concerned about customers perceiving the need to choose between NetDocs and Outlook, knowing how much of the Office value proposition was built around communication scenarios using Outlook.

For all the good ideas and hard work, a clear decision was needed. We discussed alternatives with the leaders on the team. There were well-deserved mixed feelings and some significant pushback, and honest emotion. The leaders on the team knew the facts and challenges, and so did most of the team.

Brian met numerous times with BillG and SteveB. Along with the NetDocs leaders, JeffR, Brian, and I met with BillG to decide on a plan to ship NetDocs with Office or not, and not shipping probably meant shelving the project. Brian hated this kind of meeting. Showing up with two options always meant debating a third option. When it came to this level of technology and product, however, it was increasingly difficult for Bill to have the best or most informed opinions. The company was made of so many brand-new products and technologies, no one could keep track. The NetDocs team was exhausted. They had worked tirelessly for the weeks leading up to these meeting to see just how much they could get done. Knowing them well, I could sense the resignation.

It was too tall an order to deliver on all the new things while maintaining compatibility with Exchange and Outlook, while advancing in all the ways they intended. It might sound like we could finesse having two products, but not for the Office business, not against Lotus Notes, certainly not for enterprise customers with new Enterprise Agreements, and definitely not for industry analysts and the press. Our credibility as a company was on the line and too much was at stake too soon in the adoption curve.

The team tried to do too much, too soon. Brian agreed with Bill that team should have focused more on XML seeing how important that had become to the strategy, and that it would have been too difficult to have a sort of slow burn email strategy where it took several releases to surpass Outlook. There were better ways to have a bigger impact, and sooner. Bill was clear he should have provided more direction to the team on priorities. There was ample humility and professionalism to go around. As painful as this transition could have been, much of the difficulty was mitigated by the level of accountability Brian and Bill demonstrated.

Brian pushed to have the refocusing of the product to XML scenarios happen within the Office team.

We held an all-hands meeting with the NetDocs team in the cafeteria, led by JeffR. While the decision was made between BillG and BrianMac, there was no escaping that some perceptions of this were about how I held control over the Office “box” and thus I ended up bearing the brunt of it, especially for those who thought NetDocs was closer to realization than not. Any meeting like this was going to be tough. Still, cancelled and redirected projects are a part of engineering and often turn out to be important lessons for many. I had just gone through a last-minute reset as well.

Few engineers make it far into a career without enduring at least one major project reset.

I was caught off guard by how much the press had continued to portray this as a battle, my battle. There were so many difficult situations, differences of opinion, and product challenges, but this wasn’t one of mine. I experienced a friction between teams, primarily over hiring, and some regarding product claims when it came to working with Exchange. The irony of the situation was the friction was mostly rooted in the history and connections so many of the engineers on the team shared. It was as if members of the old Outlook team started building a new Outlook to take on their earlier creation—perhaps a second-system syndrome as detailed in Mythical Man-Month.

When a project goes through a big change or reset, the feelings come out. When a project is in the press too early in its life, then these feelings make it to the press too. I knew enough to understand that people want to find a clear point of responsibility, even blame. I was an easy target. It would not be the first time.

It was also ill-advised to engage the press on these stories, leaving them to be based on whatever perspective was tipped to one of the Microsoft beat reporters. I understood it was clearly part of the job for me to take on accountability for things that don’t go well, even when it feels like a stretch to call something my fault. I watched every manager or mentor I had (BillG, JeffH, ChrisP, MikeMap, PeteH) do that more times than I could count. Like so many difficult situations, the NetDocs transition proved a valuable learning experience.

Many on the NetDocs team used the project reset as a chance to stick their heads up and see what other opportunities were going on around the company and beyond. More specifically, there was a noticeable exodus of middle pyramid people in this era. The core group that remained earned a unique opportunity to create an entirely new product for Office11 focused on maximizing the value of XML. That was the constraint. My view was that if they were close enough to spend all this energy on NetDocs shipping in this timeframe, then they could ship the less complex product (without email) while still having the full Office11 schedule to work. They would be able to use the Office shared code to bootstrap the entire app, which would save a huge amount of time and also make consistency and synergy much easier.

During the project, NetDocs had expanded scope broadly so as to include the universal canvas, XML editing, XML data transformation, new user interface, a mail and calendaring client supporting both old and new protocols, and many more. To support these the team grew to a significant size—over 500 people. To put that in perspective, the entire Office team was about 2,000 people including everything sold under the Office umbrella. Office maintained a long history of letting people move around the different teams (or, staying put if they chose) at the break between releases. That is exactly where we were which enabled many to easily move to other parts of Office (or other teams). Don Gagne (DonGa) who previously led Outlook and then moved to NetDocs would soon find a huge role in Office, so it was rather fortunate he stayed on. In writing this, I know that all these names can sometimes seem to be overdoing it but having read many accounts of how things happen in big companies I always feel that too many key contributors and their work are left out. There won’t be a quiz at the end.

From NetDocs, Don Gagne (previously from Outlook) would lead a newly formed team called XDocs, short for XML documents, along with Rajesh Jha (RajeshJ) leading program management. XDocs was NetDocs repurposed to an end-user tool using the XML technology using the core NetDocs code base—at a high level NetDocs without email and calendaring. There was much work to be done in that regard, including the difficult work of right-sizing the team for the task at hand. PPathe would step up as a VP to provide additional leadership in helping to integrate and shape XDocs. He brought with him a deep understanding of the history of SGML (the predecessor of HTML) and the way Word embraced HTML, which would come in handy when it came to XDocs integrated across Office.

The team went through a fast process to identify where XML technology in NetDocs could be reused. XML generated a ton of buzz in the industry as a way of exchanging data between applications. We increased support for XML in Excel (for example, the SEC began requiring companies to release quarterly earnings in an XML format, making it easier to import into spreadsheets or databases for analysis). BillG was now actually excited about XML in Office11.

The Infopath team under RajeshJ’s leadership was one that appreciated that diversity of the team helped to build a better team and better products. Early in the product cycle the team made this video introducing members of the team.

Leading the effort to create a vision for XDocs was Judy Lew (JudyLew). Judy joined Microsoft about five years earlier out of the University of Michigan MBA program. She attended Columbia University as an undergraduate and her pace in words and action was more New York than her Utah upbringing. She was thoughtful, analytical, and persistent, traits which served the team well in pivoting to an entirely new product.

Her research identified a tool for companies to create forms—expense reports, invoices, surveys, and more. She envisioned enabling a much more elaborate experience and including programmable logic, data validation, and connectivity to other data sources to make it easier to fill out forms—a significant benefit, it could function without being connected to a network using offline email, which was a huge win at a time when getting online was incredibly difficult. Such a product could help in competing with Notes.

XDocs showcased SharePoint to share forms and store the results of the data collected. Competitively, IT developers were starting to use web browsers for many applications and were often seeing limitations of HTML compared to how these problems might have been solved with tools like Visual Basic.

To put XDocs in today’s context, it was designed to solve many of the problems solved by DocuSign today. Before web browsers were as capable as today, having a desktop application where the form to be signed and manipulated came together was a good idea. As it would turn out, leading customers were perfectly happy dealing with the limitations of browsers and HTML if it meant not deploying a desktop application. There was an extremely important lesson in there. The era of looking to solve new problems with a new Windows application was over. I was increasingly convinced of this fact. Not only was this an unpopular opinion inside the company, but the company strategy also assumed this was decidedly not the case. The problem for me was the Microsoft bubble with influential enterprise customers and the strategy bubble inside the company were protective enough that it would be years before the reality of our situation would be shared.

If having to outright cancel projects was rare, rarer still was the opportunity (or ability) to pull from the ashes of a cancelled project an entirely new product that, at least at the time seemed strategic and viable. The team, and the broader Office team, were excited by the work. Judy Lew’s efforts were remarkable as was the execution for the remainder of the team. It was not our best product (in fact, it was a failure in hindsight, the right problem to solve but the wrong technology approach) nor was it the most exciting to work on but going from a long trek of not shipping to creating a credible product so elegantly was a noteworthy accomplishment. The team left behind a consumer subscription product for email to build an enterprise business process tool using XML. They delivered and that was a huge accomplishment in this era—so many new ideas failed to gain escape velocity. As Brian said in his mail to the team announcing the changes, organizing in Office would be a huge opportunity to ship on time and to maximize the potential impact of the product.

InfoPath, the final product name, shipped with Office11 as a full-fledged module in a business SKU. It showed off a strategic new technology, XML, along with SharePoint and Outlook, and it helped to compete with Notes. It provided the kind of strategic demo of business value that the salesforce appreciated. It was the kind of product that Microsoft Press, Microsoft’s book publishing subsidiary, pursued aggressively resulting in a book even before the product released. I fondly recall stopping by Rajesh’s office when he showed me the book, beaming with pride.

InfoPath was bundled in an Office enterprise SKU. Doing so brought great distribution but made it difficult to realize the true value. As with Outlook, the desire to support the bundle was greater than any incentive or perceived opportunity to create a new business. JudyLew’s work clearly identified the revenue opportunity and specialized customers for this type of product. Reaching them, as is often the case, required an investment in new sales and marketing people and programs.

Sales and marketing did not share those views—their priorities there were to increase the perceived value of Office, particularly signing new and renewing enterprise agreements. XDocs had the beauty of being a high-end tool for IT while being useful to every desktop in an organization, which fit in well with the EA.

From my perspective, I faced another round of being on the hook to deliver organic innovation that expanded to new categories, only to see the work turned into incremental innovation to support the existing Office bundle. The pressure to drive upgrades was greater than the need for more organic growth, yet it was clear no one was going to upgrade for InfoPath more (or less) than for any other feature in the bundle. The difficulties in upgrading were unrelated to the value proposition of any part of the suite. The complexity of the overall platform of Windows and Office cemented a view that any change introduced upgrade friction. As we saw with browsers, if something interesting came along that was entirely new rather than simply an upgrade, customers were more than happy to consider adding to their standard deployment. We never got the chance to see if InfoPath was interesting enough to consider as a new addition to the enterprise platform. It was just more bloat.

I was disappointed that we chose to simply add more bloat to the perception of Office, as reviews would say, rather than strive for new business opportunities. The revenue for Office kept going up, either demonstrating I was wrong or perhaps proving that with the product-market fit we achieved for the core suite, nothing else we did could impact the suite business.

Still, this was difficult for me. Clearly, I was responsible for what ultimately transpired in the NetDocs to InfoPath transition, at least to the degree that I advocated for the only rational choice technically and in the context of EAs and the business. On the other hand, I was not the one who let the product go on for a couple of years nor was I the one who insisted on the demo at Forum 2000 (and numerous other demos to all sorts of industry people). NetDocs had enough external exposure that it was clearly perceived as a super cool product under development—at least based on that cool demo at Forum 2000 (why else demo it?). Would it have been better if it were permitted a slow burn over several years? I have my doubts, as the technology seeds that it contained were inside the Microsoft bubble, not where the industry was strongly heading. Instead of a Win32 app and proprietary XML, Office would double-down on browser-based tools starting in the next release of Office. Ultimately, the product just was neither different enough from everything going on nor did it take a radically different approach that could come from a new technology.

Thanks to me, I suppose, NetDocs was one of several products on every list of legendary Microsoft products that never made it to market. Much later, another one of those products caused me and the company a considerable amount of grief.

Stay tuned.

InfoPath was not the only new product in Office11…

On to 072. Notes on Tablet PC Innovation

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