Who decides what features go into a software product? If a software product doesn’t have a feature, why is that?
My entire career at Microsoft has been as a Program Manager. You can probably read elsewhere exactly what that means, but for now we’ll just say that the role is one of “make-it-happen” guy. Another way to say that is if anything is not successful during a project, the program manager shares the blame since they were supposed to foresee it and do something to make sure it didn’t go wrong. Program managers do a wide variety of things – they speak to customers or potential customers, they read about technology, they try to understand businesses and individuals and what their productivity problems might be. The higher level program managers also hammer out a “vision” for a product. This is often a collaborative effort, involving many other program managers in other products. The idea is to figure out the optimal set of things we can build to make our products valuable to customers, which in turn leads to revenue, etc.
During the course of a software project, we have many processes designed to cull poor ideas out of the set we have thought of, or to remove ideas that might be great but do not fit the grander themes we have chosen for the release. In Office years ago we used to just do a lot of things that seemed valuable, but we found that when you go to explain what the product is, a thousand disconnected things are much harder to articulate than a thousand things that support three big value points.
At some point when we think we have a pretty good idea of the most important things we are sure we are going to do, the program managers start figuring out what these will look like and how they will work. As part of this process they build design documents. These are increasingly visual click-throughs (sometimes just handwritten drawings) that give us a sense of how a feature (one with User Interface) will work. This is an organic process of design, which is both highly individual at times, and also highly collaborative.
Some people imagine that BillG simply orders us to do what he thinks is important. If that were true, none of us would work at Microsoft. The great thing about the company is that you have the flexibility to do what you think is right, and make decisions at your level. Of course, you don’t make decisions in a vacuum – you spend a lot of time convincing your peers that your view is correct. This process helps you hone your idea to make it better based on feedback, or convinces you and others that it is not such a great idea.
In order to move things forward, we have a set of meetings called “adds/cuts”. As we build up the list of feature ideas, it inevitably grows way beyond what we could implement in a given two year time frame (the normal release cycle for Office products). For example, with OneNote, we had so many ideas that we had to ruthlessly cut out anything that wasn’t strictly required for the product to function, and then carefully used the small remaining budget to enable 10-15 features that we thought were central to the “version 1” goals we had: make a useful personal information capture and retrieval tool. Having a clear goal is critical to making a good software product. We used the vision document I wrote in early 2001 as a guide and made sure that we were all in sync on what we were actually building. It had to support about five key scenarios: note taking (both externally and self driven), researching, organizing, and retrieval.
At times people would become enamoured of some idea or another in isolation, but the shared vision, the requirements to make the key scenarios work, and the very limited budget for non-necessary features meant we had to drop anything that was off-mission. “Save it for version 2”.
Now, I often read or hear from users of OneNote (or Word, or whatever) that we don’t have Feature X, and that must be because we didn’t think of it. I smile at this, because it is sort of cute to think that we just sit around dreaming stuff up, and whatever we dream up goes into the product, as if development realities didn’t exist and we are limited only by our imagination. Or, I suppose I could view it as insulting – that what is in the product is by definition all we could think of. The reality is that we had enough ideas to fill the features lists of at least the next three versions, and the only reason we didn’t have more was because we were forcing ourselves not to keep dreaming up new stuff and to get cracking on defining the details of what we had decided to do.
So, why don’t we have an extensibility API? Of course it MUST be that we didn’t think of it, right? Or that we didn’t realize that it was important. Say the same for drag and drop arrangement of sections and folders and pages, or multiple views on a notebook, or real-time note sharing, or PocketPC integration, or rich integration with the Journal application on TabletPC, etc. etc.
If we had allowed ourselves to go off and do these things, other features currently in the product would not exist, and people would be saying: “What were they thinking? This product isn’t even useful – why did they build an extensibility model for it instead of putting in the features that make it worth extending?”. Of course, we don’t always make the right call – sometimes our judgment slips and features get done because we thought they were cool, rather than because they were critical. Or the process gets us – we don’t discover our design was incomplete until too late, and there is not enough time to fix it properly. We don’t think of everything of course – but with more than two years spent every day thinking about the problem space, odds are we have thought about it and have decided we can’t afford to do it (this time around). Keep your suggestions coming through – even if the idea isn’t new to us, every time we hear an idea it is a vote for doing that feature in the future.