About

I am a software developer in Seattle, building a new AI software company.

Ads

May 2008

Sun Mon Tue Wed Thu Fri Sat
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Recent Posts

Ads


« Language Oriented Programming | Main | Socially Clueless »

January 30, 2005

Planning a Product Years in Advance

When developing a new product that will eventually ship years after the planning stage, it’s important to remember that the competitive landscape will be very different when the product actually ships.

When Office 97 was originally entering the planning stages in 1994, Netscape did not exist and Microsoft employees did not have access to the Internet, consequently there were no Internet features. Lotus Notes, a platform that Lotus could leverage to sell SmartSuite, was perceived as the major threat to Office, so workgroup features—simultaneous editing, versions, document comparison and merging, revision tracking in both Word and Excel—became a major theme of Office 97 release.

The press was abuzz with the coming emergence of an Information Highway, but didn’t seem to equate that with the Internet. When Office 1995 (developed simultaneously alongside Office 97) shipped in 1995, the significance of the Internet became clearer, but the new suite offered no Internet features; an Internet Assistant add-in was cobbled together to enable Word to read and write HTML files.

Many in the industry began to see the Internet as the death knell for Microsoft, so much so that Microsoft had to arrange a major analyst meeting in December of 1995, where it announce several new initiatives like ActiveX, products and partnerships, such as the ill-fated Java partnership with Sun. A Bill Gates company memo “The Internet Tidal Wave” mandated that every Microsoft product now had to include Internet functionality. (There is a parallel today, where after a similar Bill Gates security memo, “Trustworthy Computing,” was released, where every product must now support security and undergoes a full security review prior to shipping.)

In Microsoft Office, several new Internet features were added after months after Code Complete. The Internet Assistant add-in was baked into Word. An Excel intern developed support HTML load/save late in the project. The Reading View, already in development, in Word morphed into Online Layout. (The original Reading View was apparently revived in the Word 2003, as the Reading Layout.) The Internet made the Notes juggernaut irrelevant. Old priorities like simultaneous editing in Word were dropped.

The lesson is that times changed. The software industry is dynamic; new competitors and products are always emerging. Products will face a different reality from when they were originally designed, so it is important to think ahead, when the product won’t be released for a long while.

My own product concept is very futuristic, probably ten years ahead of its time when I initially conceived of it around the beginning of 2001, although it really was the culmination of a decade of thinking since my studies at college. I didn’t actually start any design or development work until 2002, after spending a year constructing a business plan in my MBA program.

Every so often like this past week, I read an article, in the Wall Street Journal or New York Times, which sends chills up my spine as I discover that other players in the industry are moving ever closer to my space, but haven’t quite “gotten it” yet.

 

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/t/trackback/5190/1749853

Listed below are links to weblogs that reference Planning a Product Years in Advance:

» Features Dropped, Features Gained from notgartner.com: Mitch Denny's Blog
[Read More]

Comments

which sends chills up my spine as I discover that other players in the industry are moving ever closer to my space, but haven’t quite “gotten it” yet.

It's all about execution in the end, not just "getting it..."

One way to prepare for advancements of the future is to make a plug-in extendable architecture available in your software, and/or an API.

If you look at the Windows API, it pretty much offers a virtually unlimited amount of future extensibility for windows - one (the main?) reason why windows is so successful.

Even if windows was open source, it still needs an underlying API so things can talk to each other without needing to be recompiled. Having the source code available in addition to the API would be an advantage, but an API is more important factor for the mass than thousands of lines of source is.

I think that's why the release of windows source code didn't really matter: the API is more important, it's not like we are going to all recompile windows each day to make minor changes and hacks in our systems. That's what an API is for.

Yet I continually see applications out there that are compiled and closed shut with no API. It's like they are toaster ovens and I can't even control the temperature.

If you create a program that has wonderful features, but cannot be extended.. there is a huge "in the future, things change" problem.

The other key is making your software reasonable: if the plug-in architecture makes your software run slow then people are going to consider that factor. The windows API isn't slow, but things like Java can be.

Post a comment

If you have a TypeKey or TypePad account, please Sign In