Why Doesn't Windows Home Server do foo?

  • Article

When someone asks "Why doesn't Windows Home Server do Foo?" a response of "because" goes just about as well as it does when my son asks "Why can't I just eat chocolate for dinner?"

This post is an attempt to generically answer the "why not" questions by explaining the process my team used to plan Windows Home Server.

First some universal truths about product development (if you know who Joel Spolsky is you can skip this section; I'm not telling you anything you don't already know):

  • Shipping is a feature too. At some point in the development of a product (particularly software products) you have to start saying no to all new feature requests. Otherwise the phenomenon known as "feature creep" will cause the project to spiral out of control and it will never ship, or will take so long to ship that the value of all of the features to the consumer is greatly diminished.
  • The mythical man-month. Resources are not infinite and even you could add more it does not help get more done faster.
  • The quality bar, the time you have, and the feature set are directly correlated. They are the only knobs available to software development project managers. If your quality bar is fixed (and it should be) and you want to get the product into market at a particular time, the only variable you can adjust in order to ship the product is the feature set.
  • There is an inverse relationship between the number of people involved and the scope of the project. Successful products are started by a very small number of people with huge ambitions and are finished by a much larger number of people with razor sharp focus. How a team gets focused while reaching a critical mass of resources is a critical success factor for the project.

Then there are the first principles of a project.  These help a team form a decision making framework for the project. There are dozens of different approaches that projects have taken over time; some have proven very successful, and others resulted in utter failures. In the case of Windows Home Server, we chose the following first principles:

  • Focus on a specific market segment; in this case households that already have multiple PCs, broadband, and a home network.
  • Provide solutions, not features or technologies. Solve end-to-end scenarios.
  • Don't ask users questions they can't answer.
  • Pick a few things you are good at and do them really, really well.

As is the case with most new product ideas we had a "jewel of an idea" that would serve as a cornerstone for everything we did. The nucleus of our vision if you will:

"A home server is an always available smart node on the home network dedicated to providing services to other nodes on the home network and the Internet."

This is an insanely broad definition. Clearly you can't build a product around something so broad, but you can develop a long term vision.

So, if you assume (as we obviously do), that a home server is a good thing and Microsoft should build an operating system for one, the question becomes "what specifically does it do?"

Early in the planning process we used a combination of brainstorming, secondary research, and our prior experiences to create a taxonomy for categorizing all of the things a home server could do. Because we are solution and scenario focused it makes sense for this taxonomy to start with "Scenario Areas" as the highest level bucket.  We identified 11 scenario areas where a home server would be valuable (valuable to customers, end-users, Microsoft, 3rd parties,  etc...):

PC & Network Management

Home Network Infrastructure

Storage

Data Protection

Publishing & Sharing

Anywhere Access

Communications

Entertainment

Family Applications

3rd Party Platform

Enthusiast Playground

 

Within each of these scenario areas, we identified 10-20 end-to-end scenarios resulting in several hundred total scenarios.  We spent just enough time talking about each scenario to be able to have a succinct description (one short paragraph max).  For example, within the Anywhere Access scenario area we wrote down the following scenario:

"When you are outside of the home, you can search for specific files stored on your home server, even if you can't remember the specific name(s) of the files"

In order to provide a solution for a given scenario one has to build software features and technologies. So we also identified the features and technologies that would be required to provide a solution for each scenario.  This "book of scenarios" painted a pretty clear picture of just about everything anyone could imagine a home network doing. It was a lot of fun creating it because we all got to basically dream up every cool idea possible.

It would take decades to build a product that delivered solutions for every scenario we documented. Our ambitions were huge, but to be successful we knew we had to get extremely focused. To get the list of things to do down to a size that was believable we used a combination of the following:

  • Secondary research
  • Primary research
  • Industry trends
  • Available technologies
  • Available resources
  • Engineering competencies
  • Knowledge of other Microsoft product's strategies, visions, and plans
  • Business model
  • Schedule
  • Results of prototypes
  • Estimated costs (people and time) to develop and test features and technologies

We spent about 6 months in this process, going from several hundred scenarios (a 360° view) to a list of a few dozen scenarios (a 30° view).  To do this we decided to completely ignore whole scenario areas and hundreds of scenarios; we drew a line in the sand and said

"We have decided to climb these mountains in v1 and leave the others for another time".  

"These mountains" are

  • An easy to use consumer experience on top of the most powerful operating system on the planet
  • Automatic multi-PC backup and simple restore
  • Easy to expand reliable centralized storage
  • Anywhere access

The common theme for these are reflected in our mission for v1:   ...helping families with multiple PCs connect their digital experiences, providing a familiar and reliable way to store, access, share and automatically protect what is most important

It was at this point in time that we could start to really formulate an actual product plan. But even that 30° field of view is too great for a single release. So as we finalized our multi-year, multi-release product roadmap we made even more "cuts".  Comparing the literally hundreds of possible scenarios we could have focused on with the few we will actually deliver in v1 - I'd say our field of view is around 15°.  And given the amount of passion, hard work, and dedication all members of the team have poured into the product and our progress so far I'm confident that we've found just about the right balance.

I started this post with the question "Why doesn't Windows Home Server do foo?". Hopefully, if you've read this far I was able to show you the process we used to decide what Windows Home Server will do in the first version. And as a corollary this explains why certain capabilities will have to wait for subsequent versions.   

-cek