I want to address the topic of requesting feature changes in Microsoft products, to point to some tools that can help, and to describe ways to use those tools more effectively. This post is based on my experience working on customer requests while being a member of the Microsoft SQL Server team, but you may find the information I provide here useful for other Microsoft products than SQL Server.
So, basically, the problem I am discussing here is that you are working on some project using Microsoft technology and you find out that your work might be much easier if only some feature would be available. How can you ask Microsoft to add that feature to their product? One way to do this is to contact technical support, but there are other ways that I want to address here.
Before I start, I should mention that if the problem you are confronting appears to be a security vulnerability, then there is a dedicated site on which you can provide a description of the problem to the Microsoft Security Response Center. Needless to say, security vulnerabilities are addressed with higher priority than the addition of new features and the rest of this post deals with the latter.
Also, while I am talking mainly about requesting features, the steps I present would be similar if you what you need is a bug fix.
Step 1 – Information gathering. Before a feature should be requested, it is important to do a bit of research to find answers to the following questions:
– Does the feature allow you to achieve something that is worth achieving?
– Is the feature absolutely needed or are there existing features that can be used to achieve the same goal with approximately the same effort?
– Has the feature been requested already?
The easiest way to find the answers to these questions is to ask around, and the places you can ask these questions online can be divided in two categories:
– public forums, such as the microsoft.public.* forums or forums hosted by various sites focusing on the use of a specific Microsoft product
– Microsoft forums, such as the MSDN hosted forums at http://social.msdn.microsoft.com/Forums/en-US/categories/
It is worth keeping in mind the differences between these categories of forums. Each offers specific advantages and posting on the right forum is a great step toward getting a quick and appropriate answer. An advantage of public forums is that they can be used to ask a wider array of questions – for example, you can ask questions related to the interactions between Microsoft products and other products. Microsoft forums have the advantage that they are monitored by members of the product units, but they are usually more focused on discussing specific features of a Microsoft product.
As usual, before posting on any forum, you should take the time to search for existing threads that may already answer your questions. This is good forum etiquette that is expected on most forums and that their frequent contributors will often suggest, because it reduces the redundancy of information in the forum and thus increases its quality.
Once you have the answers to the above questions, several things can happen:
– you may find that the request is not necessary either because it does not really help solving a problem (in security it is often the case that a mechanism can be perceived as improving security when it really does not do so) or because there are other alternatives of solving the problem
– you may find that a request already exists and you may be provided with a way to track its progress or with a status update about the plans for developing and releasing it
– you may find that you may be the first customer to request the feature
If you are in the latter case, the next step is to ask formally for the feature.
Step 2 – Filing a request. Depending on the product, there may be various ways to ask for features. One way could be to just ask a member of the product team that you contacted online or at a professional conference to open an item for the request. But some products allow you to directly open requests online using the MSDN Product Feedback Center. The Feedback Center is a very powerful tool, because the item that you open is directly viewable by the product team. When opening a new feedback item, you should include all the information needed to describe the problem you are facing. You should also update the forum thread that you started at the previous step, to include a link to the feedback report that you opened. This will help you by helping others notice your report so they can vote for it – the more votes your proposal gathers, the higher the chance that it will be assigned a higher priority that will allow it to go ahead of other requests.
While in the SQL Server team, I have been on the receiving end of such requests and I have solved many of these (solving them meaning that I made the required changes to the SQL Server code); I also saw requests for existing features or for features that wouldn’t accomplish anything useful, which is why I am emphasizing the importance of the information gathering first step. Some of the features I added were important enough to ship in the next service pack (like some of the features mentioned here), while others were postponed for the next release, but the important thing to note is that in all cases the requests got directly to the development team. In most cases, I also provided feedback back to the customer about the progress made and the plans for releasing the changes. My point here is that this process works better than you may expect. As far as I know, no other company provides a way for customers to directly contact the development team.
What next after filing a request?
Step 3 – Monitoring your request. After you made your request, the next thing to do is to monitor it, to provide additional information if needed, and to check for any developments. Feedback items have a great feature in that they allow a two way communication with the product team. As long as the state of your request does not change, there isn’t much that you can do other than making sure that other people that ask for the same thing know about your request and vote for it. Each product will have its own schedule for releasing new features. Service packs usually contain high priority fixes so if your issue is not high priority, you can only expect it to show up in a future release. Bugs have a better chance of being resolved than new features have to be added, because they usually involve less code changes. Also, bugs usually get fixed all the time, while features tend to compete against other features for a larger set of resources and they only get worked on during specific periods in the development cycle. Finally, a problem for which a workaround exists will get a lesser priority than a problem with no workaround.
This is basically it – I hope this information helps you figure out how to make use of the resources I listed. I’ll end this post with a summary of all these steps:
– Search to see if your problem has already been discussed. If yes, then join the existing discussion.
– Open a new request if your search has not uncovered one. Provide all information someone would need to understand your problem.
– Track your request, to provide additional information, if needed, and to check for status updates.
Finally, keep in mind that forums are great sources of information, but they don’t help that much with tracking feature requests – the best way to do that is offered by sites like the Microsoft Product Feedback Center. So once you have a feedback item opened, make sure that other people having the same problem will vote for your feedback item.