In a recent comment, Michel asks:
How do you come up with a list of new features that are to be included in a new release?
In a 'Meet the Expert' session here in the Netherlands last December, I discussed a problem for which ' the expert' knew a ' feature design request' was already on the list: how did it get there? Not my single PSS call I assume..
Great question. As usual, it's not an easy answer. There are a ton of inputs that go into the list of things that we might include in a given service pack or release. Of course, we strive to include only bug fixes in service packs, but sometimes these features are such a high priority that we must include them in a service pack. Some of the inputs include (in no particular order):
- Customer escalations via PSS (MS Product Support Services for those who are lucky enough not to have needed to call) or Premier support. The term that the Microsoft person used is Design Change Request, or DCR. This is our term for a change to the product after it's been released. It is unlikely, Michel, that your single PSS call resulted in that feature being on the list of things to be done, but when someone asks for a feature through PSS it can result in a “tick mark“ in a database.
- MSWISH. This is a way that anyone can make a product enhancement suggestion, without needing to call PSS or have a support contract. The URL is http://www.microsoft.com/mswish. You can fill out a web form there, or send email directly to email@example.com. All of these entries do go into a database that ends up at the appropriate product group. This isn't just for Exchange.
- Product Group brainstorming. We may have a developer, tester, or program manager who comes up with an idea and champions it. They will typically solicit customer feedback, and fight for the “ticks in the database” that will get it done. They may also harvest data from PSS call logs to see who called in with a problem that would have been solved with that fix. They may communicate via email with our MVPs (Most Valuable Professionals) to ask their opinion: have they seen a lot of this on the newsgroups, does this sound like a good idea.
- PSS feedback. PSS classifies customer calls, and they keep track of the types of problems that cause the most customer calls. Then they give that feedback directly to us in the product team. They say “if you were to make this easier, then these people wouldn't have had to call“. That's an incredibly powerful tool because it shows you exactly which things you can fix or improve that will result in a direct improvement in customer satisfaction. Because after all, no one wants to call PSS. (even though they are very nice to talk to)
- Microsoft Customer Experience Improvement Program Data. The CEIP is a fairly new tool that we have introduced in a number of products, including MSN, Messenger, Windows Media Player, and Office. For those customers who opt-in to send us their anonymous usage statistics, we can see a picture of their experience using the software. We don't capture data from their files, but rather how the program is being used. As a hypothetical example that I just made up, let's say that we saw that a huge number of people using Outlook go into Tools -> Options... -> “Other“ Tab -> Advanced Options... -> Reminder Options and turned off “Play reminder sound“. We might make the default be to not have a reminder sound in the next release. Or we might put that setting in a more prominent place. You can see the potential. We also use this to look at what kinds of error dialogs people run across. Sometimes we aren't sure how often a particular error will be hit in the real world. If we see that something is hit often, we might be able to put code in place to prevent that condition from occurring in the first place. It helps us know where to spend our time to know what will be the biggest bang for the buck for the customer.
Now I have talked about these “ticks in the database” - these are virtual ticks, there is no set threshold after which a particular feature will get done. The amount of proven demand necessary to do a particular feature will vary greatly depending on the difficulty of the work. For example, if something needs work done in Exchange as well as a change in Outlook, you can imagine that it takes a lot more persuasion and customer data to get that done. Once the decision is made to do a DCR, then we decide what is the most appropriate release. Do we need to correlate it with an Office release, etc. Sometimes, unfortunately, as we start to do the coding or test the feature, we find that it didn't work the way we initially expected or it was more complicated, and we have to re-think the feature. This is one reason that we don't like to discuss upcoming features until the product is very close to being released: you never know when something will need to be cut because of unforseen circumstances.
I hope that demystifies the process a little bit.
You know.... an RSS connector would be nice... :)
After updating our mailservers with Mydoom.b@MM protection (in the middle of the night here in the Netherlands, second time this week) I checked a few blogs: My question answered! Great!
It sure helps to demystify the process, but also shows there is no direct contact between developers and customers. PSS, a product group or reports form software tools are always 'in the middle'.
You mentioned discussing upcoming features well before releasing it is tricky, it might be pulled and disappoint many people. But that's actually waiting very long before making a new feature announcement, not discussing it IMHO.
One thing that irritates me is that Microsoft as a whole develops new features that are almost exclusively ON by default. I'm not sure whether they're on because the PM thought this nifty new feature was so important that everyone will want it or if Microsoft is afraid of wasting development work on features that will "never" be used. In the worst cases, the feature may not have enough merit to simply be on by default, but it's such a "valuable" feature that Microsoft insists on disrupting my work to ask me whether to continue using this feature.
Some examples that come to mind: AutoComplete for IE, password remember feature (and its associated annoying confirmation dialog) for IE, personalized menus in Office/Windows, Customer Experience programs in Messenger/Office, visual styles in WinXP, window 'animations' when minimizing/maximizing, the 'click' sound when navigating pages, and doggie search in WinXP. All of these rate very low on actual customer experience improvement but very high on the degree-of-annoyance scale.
Perhaps my view is a little skewed because I use the computer as a tool to get my work done, not a distraction to prevent me from getting my work done. As a technical user, yes, I have customized my computer to turn off these silly defaults, but does that mitigate the fact that millions of other users couldn't care less if IE is blocking a cookie and will notify them with an "eye" icon in the status bar? Or the fact that hundreds of them will call my support desk to understand this message box asking them whether they want to send an error report to Microsoft?
PM's: Your job boils down to the decision on whether or not to include a feature, and to a lesser extent whether it should be on by default. Don't take the cowards way out by creating a new "do you want to continue using this?" dialog. Include more features, bother me less. It's a trade-off though - instead of bothering me when I'm trying to get my work done, allow me to configure this specific setting via the GUI, through a command-line interface, by registry settings, WMI scripts, COM calls, an API, and Group Policy. And via telepathy if you can get all those.
One micro-comment and then a general one:
But in general, I do agree that it is a trade off that sometimes we do right and sometimes we do wrong. I'm sure that you recognize that if the feature is turned off, and the way to turn it on is to go into the 4th level of menus and franticulate the chromolator, no one will ever use it and we wasted our time putting it in. In that case it would be better not to have put it in, and kept the code simpler.
I personally am a huge fan of "No I don't want to do that and never show me this again", because it's once per install. I know that I install XP 20 or 30 times a year, but I am a severe corner case. My mom installs once every 3 years. Having to click something to tell it to go away once every 3 years seems reasonable.
The other thing I'll say is that with our new "Trustworthy Computing" initiative, the idea of "default to secure" has been inculcated into the company. We shipped Exchange 2003 with POP and IMAP disabled by default. It's a bit of a pain to turn them on, you have to go into the Service Control Manager and enable them. But if there was ever a security vulnerability in that service, at least most people would not be able to spread the problem. So I think that is actually working.
And finally, whenever I do one of those 20 or 30 installs, I always right-click start menu, choose properties, and select "Classic start menu". Yes I consider it a bit of a pain, but I have personally seen quite a few beginners who find the Windows XP new-style start meny to be more friendly and most importantly, "obvious what to do next". I think that's the key of UI design, and I think that for people who don't know exactly what they want to do before they hit Start, the new style is the right way to go. Luckily it's about 4 clicks to turn it off for good for the relatively small percentage of experts like you and me.
PS. My mom likes the "doggie search".
As I recall, the top ten most requested Outlook features are already in the product! They're just off by default so nobody even realizes that they exist.
Heh, sometimes we need to add "features" to a product that really just make it easier to find the features that were introduced in the last release. "Meta-features," if you will.
"Discoverability" is a huge thing for usability and for getting the most out of a product.
David Lemson talks about how features make it into exchange. I have been thinking alot lately about Exchange and SharePoint and their integration (or lack thereof). Since David mentioned that the product team solicits through MVPs and blogs, I figured I would post some of my ideas here. I feel SharePoint and Exchange integration is a must for both products going forward. Each product would benifit significantly from such integration. First off, one big complaint I hear fairly often from the SharePoint community is "How do I easily copy mail to a SharePoint document library?" Usually this request is to easily make mail searchable. The problem is that to copy a mail to a document library, it must be manually copied there using the Save As command in outlook *and* the message must be saved as a text document so it can be crawled (.msg files cannot be crawled by SharePoint without additional software). Sure, SPS can crawl Exchange public folders, but only through OWA and even then, it isn't the best solution because it just provides a connection between SPS and Exchange, but not true integration. OWA must still be used to access any items in the public folder. The next place I can see where integration would be extremely benificial would be with calendar/events integration. Right now, you can view events in Outlook in a side-by-side calendar, but this information cannot be updated from the outlook client and your Exchange mailbox knows nothing about this. The same can go for tasks. For example, I would love to have my exchange calendar synchronize with SPS events (from certain sites/lists) and show them on my calendar with some form of flag that it is a SPS event (say a different color). This way, these events would show up in my...