Probably the best chapter so far, thank you! I can literally feel anxiety through it and I can only imagine what it was to make all those bold calls you and the team had to make with all the external pressure and uncertainty of late 90s. Great time and memories.
Are you going to write something about Office 2007 and the ribbon? It must be a great story too and thriller as well. I still remember myself asking people around what is the most used command in the Office UX. Almost everyone was shocked with the reality :-)
Thank you so much! Yes for sure will write about that. Lots between this time and when the UI redesign happens to share. I hope that is as interesting.
Great chapter. Echo comments below that this is one of the best so far. It's interesting to read that platforms / systems were technology driven and apps were scenario driven. In retrospect, were the transplanted tech-driven discussions the right approach for Office at the time?
After switching to product management in my post-MSFT career and working at large companies in the Valley, I've found these companies to be very allergic to tech driven strategies, esp coming from the PM organization. Everything must "start with the end user" or "work backwards from the use cases". This helps prioritize investments to maximize user value but can also be short sighted when it comes to making deep investments in durable strategic technology.
Thank you! Yeah it is very difficult to start from a user and build a technology product. Also no user ever wants a rearchitecture and so you go through crazy hoops to justify doing what is clearly needed from a long-term perspective and impossibly difficult to justify. Look how long it took some companies to move to the cloud because no one wanted it. Or the graphical interface decades earlier.
How do you strike the balance between investing in buzzy tech for tech's sake vs tech that is strategically valuable/critical?
It's really hard to know a priori. Eg the architectural concept of the network PC was clearly recognized as important in the 90s, but it didn't materialize in a successful way until 15 years later as the Chromebook.
Same for Java's write once, run anywhere. Java failed at that but the concept was successfully realized in Ajax web apps. Betting on Java would have been the wrong answer but I imagine that was far from obvious at the time.
Super interesting question. I wish there was a good answer that doesn’t sound as obnoxious as the one I’m going to offer. The lesson I learned working in Silicon Valley and watching this play out is that there are people that “just know” and they are “right”. The real success comes from letting that person decide and own execution because while they know, they won’t have all the details right and will need to change along the way but will change in the “direction of goodness” (old NASA expression).
I know it is ridiculous to say “they just know”. But time and again what I’ve seen is that within every company (or product line) facing a big decision, there’s someone who knows what to do, has a plan, and understands all the arguments in every direction and deeply understands the technology and “product”. They might be in any number of roles. But there’s literally a single person or small tight knit group.
In hindsight, that’s what really played out at Microsoft over time. The Windows 1.0 team, Word, Excel, Office, Windows NT, Internet Explorer and so on. Where the team did not know there was also no one who knew and the team went in circles for years.
Great chapter. Regarding Java for client apps it was extremely buggy. For example even basic elements like a scrollbar were too buggy to use, we had to write our own code from scratch for scrollbars for our java based Help viewer.
I found your comments about "The idea that the way to work seamlessly across multiple platforms is to invent yet another platform seemed doomed to failure" really interesting. In retrospect, I think that's exactly what happened with Java. Certainly, in the early days nothing worked well enough to actually use, something you would only discover when trying to actually use it for anything :)
I learned early on after I moved to the valley, after spending a couple years developing half of dBase III+, etc., that these companies we're talking about - Sun in particular - liked to rag on MSFT, but had no clue - I mean none - of how difficult it was to develop useful, working, PC applications for end users. At Sun, when interviewing for a database they were planning to write to compete with PC databases, I asked they head DB guru Rick Cattell to show me how they planned to develop useful applications when they didn't use any because their workstations had none, he said that Scott didn't allow people to have PCs. In 1988. Then he walked me to an air-conditioned server room with a lot of cables all over the place and a lone Compaq 286 PC sitting on a shelf that was running 1-2-3. They would go in there to "play with it".
These companies had no culture or experience to inform building components for desktop applications for end-users that I could see, in subsequent years. I saw this up and down the valley, AAPL and its alums excepted.
"On the face of it, releasing the browser that quickly did not seem risky—the biggest thing about browsers was that they were viewers, and if they crashed a user could revert to what they were reading. No work was lost, unlike if Word crashed."
You're reminding me of a conversation I had with pmarca on the way to our Developer's Conference at the Marin Civic Veterans Auditorium (I arranged to have him speak as part of our deal with NSCP) in 1995/6.
Marc asked, "Hey Gary, when is Autodesk going to start releasing products faster than once a year, like we do?". My response was, "when the only input we have to respond to is a text box entry and some clicks on our canvas, with the rest of the work just being output, we can do it.".
So much pain in that question :-) When I first became Bill's technical assistant the prior TA was working on what were called then "view files". You'd install a special printer, the output of which was an executable you could put on a floppy to send via fedex (this was 1993). NeXT had made a big bet on display PostScript which was super interesting and not at all like what Windows had with metafiles/GDI. Printing in Windows was a huge transformation from screen layout--a ton of code in Word, Excel.
Bill believed *strongly* that a huge part of the value of Office were the file formats and literally refused to discuss "view files". He hated the idea of turning files into something non-editable. He also believed GDI in Windows was a huge thing and so refused to discuss display postscript. In fact, we were hard at work on TrueType and Microsoft's own printer support to bypass Adobe (because, royalties).
When I moved to Office I wanted to get postscript support but ran into Bill and then the trial started and doing anything that looked like we'd be absorbing another company IP was off limits. This was especially true after the trial when the EU started as they were more interested in Office given that Windows already lost but the company was not split up. So taking any heat for Office was bad. This was literally the *only* time these things factored into plans.
Then the Windows team decided they needed to compete with PFD with Longhorn, the endless release started in 2000ish. As part of a thing called "WPF" which was one of the main pillars of Longhorn they created XPS. What we did in Office was a "deal" with Windows that we would support XPS, which they desperately wanted, iff we could add support to PDF. For legal that looked much more appealing--we supported "both standards".
The story of implementing it and unveiling it comes in 2005. I will tell the story then when talking about user feedback.
NeXT also made a big bet on RTF. It was the default format for rich text in the clipboard, etc. In fact, the developer's manual for RTF just reprinted the MSFT specifications. MSFT RTF for rich text. ADBE/Aldus TIFF for bitmaps. ADBE DisplayPS for graphics. What did the press say? "NeXT is completely proprietary". Oh well...
Probably the best chapter so far, thank you! I can literally feel anxiety through it and I can only imagine what it was to make all those bold calls you and the team had to make with all the external pressure and uncertainty of late 90s. Great time and memories.
Are you going to write something about Office 2007 and the ribbon? It must be a great story too and thriller as well. I still remember myself asking people around what is the most used command in the Office UX. Almost everyone was shocked with the reality :-)
Thank you so much! Yes for sure will write about that. Lots between this time and when the UI redesign happens to share. I hope that is as interesting.
Great chapter. Echo comments below that this is one of the best so far. It's interesting to read that platforms / systems were technology driven and apps were scenario driven. In retrospect, were the transplanted tech-driven discussions the right approach for Office at the time?
After switching to product management in my post-MSFT career and working at large companies in the Valley, I've found these companies to be very allergic to tech driven strategies, esp coming from the PM organization. Everything must "start with the end user" or "work backwards from the use cases". This helps prioritize investments to maximize user value but can also be short sighted when it comes to making deep investments in durable strategic technology.
Thank you! Yeah it is very difficult to start from a user and build a technology product. Also no user ever wants a rearchitecture and so you go through crazy hoops to justify doing what is clearly needed from a long-term perspective and impossibly difficult to justify. Look how long it took some companies to move to the cloud because no one wanted it. Or the graphical interface decades earlier.
How do you strike the balance between investing in buzzy tech for tech's sake vs tech that is strategically valuable/critical?
It's really hard to know a priori. Eg the architectural concept of the network PC was clearly recognized as important in the 90s, but it didn't materialize in a successful way until 15 years later as the Chromebook.
Same for Java's write once, run anywhere. Java failed at that but the concept was successfully realized in Ajax web apps. Betting on Java would have been the wrong answer but I imagine that was far from obvious at the time.
Super interesting question. I wish there was a good answer that doesn’t sound as obnoxious as the one I’m going to offer. The lesson I learned working in Silicon Valley and watching this play out is that there are people that “just know” and they are “right”. The real success comes from letting that person decide and own execution because while they know, they won’t have all the details right and will need to change along the way but will change in the “direction of goodness” (old NASA expression).
I know it is ridiculous to say “they just know”. But time and again what I’ve seen is that within every company (or product line) facing a big decision, there’s someone who knows what to do, has a plan, and understands all the arguments in every direction and deeply understands the technology and “product”. They might be in any number of roles. But there’s literally a single person or small tight knit group.
In hindsight, that’s what really played out at Microsoft over time. The Windows 1.0 team, Word, Excel, Office, Windows NT, Internet Explorer and so on. Where the team did not know there was also no one who knew and the team went in circles for years.
That's an interesting answer, thanks for engaging on the question! I guess instinct and pattern recognition play a significant role.
Great chapter. Regarding Java for client apps it was extremely buggy. For example even basic elements like a scrollbar were too buggy to use, we had to write our own code from scratch for scrollbars for our java based Help viewer.
None of it worked. It was a scam :-)
I found your comments about "The idea that the way to work seamlessly across multiple platforms is to invent yet another platform seemed doomed to failure" really interesting. In retrospect, I think that's exactly what happened with Java. Certainly, in the early days nothing worked well enough to actually use, something you would only discover when trying to actually use it for anything :)
The history of cross-platform in a nutshell.
I learned early on after I moved to the valley, after spending a couple years developing half of dBase III+, etc., that these companies we're talking about - Sun in particular - liked to rag on MSFT, but had no clue - I mean none - of how difficult it was to develop useful, working, PC applications for end users. At Sun, when interviewing for a database they were planning to write to compete with PC databases, I asked they head DB guru Rick Cattell to show me how they planned to develop useful applications when they didn't use any because their workstations had none, he said that Scott didn't allow people to have PCs. In 1988. Then he walked me to an air-conditioned server room with a lot of cables all over the place and a lone Compaq 286 PC sitting on a shelf that was running 1-2-3. They would go in there to "play with it".
These companies had no culture or experience to inform building components for desktop applications for end-users that I could see, in subsequent years. I saw this up and down the valley, AAPL and its alums excepted.
"On the face of it, releasing the browser that quickly did not seem risky—the biggest thing about browsers was that they were viewers, and if they crashed a user could revert to what they were reading. No work was lost, unlike if Word crashed."
You're reminding me of a conversation I had with pmarca on the way to our Developer's Conference at the Marin Civic Veterans Auditorium (I arranged to have him speak as part of our deal with NSCP) in 1995/6.
Marc asked, "Hey Gary, when is Autodesk going to start releasing products faster than once a year, like we do?". My response was, "when the only input we have to respond to is a text box entry and some clicks on our canvas, with the rest of the work just being output, we can do it.".
Steven, one thing that surprised me back then was the lack of support for PDF output from Office, can you explain why?
So much pain in that question :-) When I first became Bill's technical assistant the prior TA was working on what were called then "view files". You'd install a special printer, the output of which was an executable you could put on a floppy to send via fedex (this was 1993). NeXT had made a big bet on display PostScript which was super interesting and not at all like what Windows had with metafiles/GDI. Printing in Windows was a huge transformation from screen layout--a ton of code in Word, Excel.
Bill believed *strongly* that a huge part of the value of Office were the file formats and literally refused to discuss "view files". He hated the idea of turning files into something non-editable. He also believed GDI in Windows was a huge thing and so refused to discuss display postscript. In fact, we were hard at work on TrueType and Microsoft's own printer support to bypass Adobe (because, royalties).
When I moved to Office I wanted to get postscript support but ran into Bill and then the trial started and doing anything that looked like we'd be absorbing another company IP was off limits. This was especially true after the trial when the EU started as they were more interested in Office given that Windows already lost but the company was not split up. So taking any heat for Office was bad. This was literally the *only* time these things factored into plans.
Then the Windows team decided they needed to compete with PFD with Longhorn, the endless release started in 2000ish. As part of a thing called "WPF" which was one of the main pillars of Longhorn they created XPS. What we did in Office was a "deal" with Windows that we would support XPS, which they desperately wanted, iff we could add support to PDF. For legal that looked much more appealing--we supported "both standards".
The story of implementing it and unveiling it comes in 2005. I will tell the story then when talking about user feedback.
NeXT also made a big bet on RTF. It was the default format for rich text in the clipboard, etc. In fact, the developer's manual for RTF just reprinted the MSFT specifications. MSFT RTF for rich text. ADBE/Aldus TIFF for bitmaps. ADBE DisplayPS for graphics. What did the press say? "NeXT is completely proprietary". Oh well...