Status on Visual Studio feature suggestions


Visual Studio receives over 500 feature suggestions from customers every month on the Developer Community website. Handling that amount is a huge effort and we’d like to share with you how we handle this volume and the steps that we take to respond to them all. What happens to suggestion tickets after they’re opened, how many make it into Visual Studio, and what happens to the rest? Let’s find out.

Let’s start with the breakdown of incoming suggestion tickets in the past 6 months and what state they are in today. We find that around 15% of the suggestions are challenging to act on, and they typically fall into the following buckets.

11% – Closed as duplicate 3% – Closed due to missing info from customer 1% – Closed because they were not suggestions for Visual Studio

We do our best to follow up with customers to get more information where we can and move them into the next stage. For example, when making a suggestion to add a command to a context menu, it is important for us to know which context menu you meant.

That leave us with 85% left which are currently moving their way through the system. Here is the status of those tickets currently in our system:

40% – Closed for a number of reasons (more info below) 20% – New, not yet processed or triaged 28% – Under review and gathering votes and comments 3% – Awaiting more info from customer 3% – On roadmap (under development) 6% – Completed and released

Now let’s dig in and see what’s behind those numbers.

From New to Under Review

We have a filtering system that automatically routes incoming suggestions to the appropriate team within the Visual Studio organization. Within my team, we have established a weekly process to triage these routed suggestions and review status. The process we follow looks like this:

  1. Does this bug belong to my team?
    • If not, move it to the right team
  2. Is the suggestion a duplicate of an existing suggestion?
    • If so, close it and transfers all votes to the original ticket (happens automatically)
  3. Does the suggestion contain all needed information?
    • If not, ask customer for more information
  4. Was this suggestion already completed or in active development?
    • If so, close it as either Completed or On Roadmap
  5. If it made it this far, mark it Under Review to gather votes and comments for 90 days

By following these steps, most suggestions end up Under Review as we gather more data, refine any repos or requirements. These make up over a quarter of all suggestions.

Every time someone adds a new comment to an existing ticket, we receive an email, so we know what’s going on with each ticket along the way, and can respond if needed.

Moving on from Under Review

Within 90 days, we attempt to address items that are still marked Under Review. Our options are:

  1. Mark it as Completed because we implemented the suggestion
  2. Mark it as On Roadmap because it’s in active development or will be very soon
  3. Close it because it didn’t get any votes and/or we’re not able to prioritize it

When we implement a suggestion, we mark it Completed or On Roadmap. Currently, approximately ~10% of the incoming suggestions go on to be implemented or added to the roadmap.

But what about the ones that don’t?

Reasons for closing suggestions

Most suggestions are good suggestions and it’s always painful to close them. Especially because a lot of them are some that we personally would like to see implemented. As developers, you know that time and resources are finite, which means we can’t implement all suggestions.

The reason we close suggestions is a mix of multiple factors, such as:

  1. It didn’t receive any votes after 90 days as Under Review
  2. It got a few votes, but an implementation will not fit within our available resources
  3. It involves areas in Visual Studio that see little usage by our customers
  4. It has negative side-effects such as degraded performance, accessibility etc.

Over a third of all suggestions end up closed due to one or more of the above reasons.

On the positive side, even for some suggestions that we close, we do move the capability into an experimental extension for Visual Studio. This allows us to lower the cost of delivering a quality product investment, and where we can draw more interest from the community.

Suggestion completed

6% of all actionable suggestion tickets end up marked as Completed. It may not sound like much, but it is about 1 suggestion per weekday. Let that sink in. Every single weekday, the Visual Studio engineering team implements a community submitted suggestion.

Before we implement a suggestion, we first write a spec for it if needed. Then we schedule the work item in a sprint for engineering to pick up. The implementation sometimes require work by multiple teams to coordinate, so they can each do their piece of the feature.

After automated test and compliance runs have finished, it’s time for code review before the code starts its journey toward the Visual Studio master branch. More automated testing runs and finally manually testing follows. After fixing all identified bugs, the completed suggestion makes its way to a Visual Studio Preview release for user testing and stabilization.

So, how do we decide to implement suggestions and how can you optimize the chances of your suggestion making it? We look at several things:

  1. Suggestions with many votes and continuous votes over time
  2. Suggestions in areas that see lots of usage by our customers
  3. Suggestions that are easier to implement
  4. Suggestions that would improve Visual Studio’s competitive advantage
  5. Well written suggestion with all relevant information in the description

A different way to think about it is to turn it around. Imagine someone wanted you to implement a feature in your product. It’s in the best interest of our product and customers to complete as many suggestions as possible, and we strive to do so.

The best times are when we get to make a lot of people happy with a feature implementation based on a suggestion.

We can must do better

We’ve gotten feedback that this process feels like a black box. Customers feel like they don’t get a response and they don’t know the status of their suggestions.

After submitting a suggestion, there is no transparency into the process, and it ends up closed without any good reason 6 months later. I end up feeling frustrated and angry. I don’t want to submit another suggestion just to be ignored. – Anonymous Visual Studio user

This is not acceptable. We must do better.

Some ideas that we are working on within the team are as follows. And, we welcome your feedback on what we might do more of to help you understand the process better.

First up, we want to be much more transparent about the process. That’s exactly what this blog post aims to achieve.

Secondly, we must be faster at responding to new suggestions. That means triaging them within the first week, so we can bring down the 20% of new untriaged suggestions to a minimum. It also means not leaving any suggestions to linger for months. This will add visibility into what is going on with the suggestions much earlier and throughout its various phases. We’ve made great progress with this in the past 6 months, but still have a bunch of open tickets to go.

Thirdly, we need to be better at giving reasons for closing tickets. Individually written by the program manager that closed them and not an automated response. As we’re getting better at handling the vast amount of incoming suggestions, this is where we’ll focus next.


I hope this blog post helps shed light on the way we handle suggestion and how we plan to improve. Completing a suggestion every single weekday will hopefully encourage you to continue opening suggestion tickets.

In closing, we’d really like to hear your thoughts or questions. What could we do better and what do we do well? Let us know in the comments below.


Comments are closed. Login to edit/delete your existing comments

  • MgSam

    I think you’re missing a big reason the current process is suboptimal. The feature suggestion system sucks!
    o The search function is terrible.
    o Tickets do not have public ids, so sharing existing tickets, and having the community assist in duplicate identifcation, is impossible.
    o The controls for writing up features uses a 3rd-rate rich text control which doesn’t support Markdown (why does Microsoft refuse to use Markdown controls? You guys have owned Github for nearly 2 years, just take the controls from there.)
    o There’s no way to subscribe to existing tickets.
    o Even getting to the feature suggestion hub is confusing mess. Navigate to Wait for the page to slowly load all its content. They’ll be 3 quick links on the bottom which are only for bug reporting (Setup, IDE, All). Click any of them. Now you’re on Click the Features tab. Literally the only way to view the existing feature suggestions. No wonder its so hard for them to get votes!
    In short, you need to move feature suggestions to a Github project. 
    And this isn’t related to VS- but the formatting of this post will likely be destroyed. Because the MS blog system is less functional than something from 1996. 

    • SeanMicrosoft employee


      Thanks for taking the time to let us know what needs improvement on Developer Community site. Markdown, hub page experience and community assist in duplication are among the areas we are either already working on or planning to improve in the near future. Regarding subscribing, you can subscribe to a suggestion using the follow button on the suggestion details/discussion page to the right of the suggestion title. Voting or commenting on a suggestion also sends you notifications on any updates to the suggestion. Please let me know if that helps. Thanks for all your input. We recognize search needs improvement. I’d like to connect with you and understand in more detail what specifically about search that didn’t work for you. If interested, please ping me at seiyer at so we can talk briefly and learn from your experience. 



      Visual Studio Feedback Team

    • Steve Valliere

      I agree with MgSam’s comments and would like to clarify/expand my ideas about a couple:
      * Search:  I have trouble coming up with the same words/terms that others use in their suggestions, making searches difficult.  When the search engine attempts to “help” by trying to match variations of spelling, tense, sometimes even semantics it usually (but not always) finds things even less related that I would find without such help.  And at times, I want (actually *NEED*) the search to be EXACT matches only, preferably including quoted phrases, because I am looking for something specific that I have already seen.  The current search makes that almost impossible by matching everything under the sun that includes similar words.
      * Duplicates:  The article mentions that duplication notices are (with should/will) being written by humans.  However, those humans really need to explain (A) Just WHY/HOW the current item duplicates another and (B) leave the duplicate open for at least a couple days to give the original poster an opportunity to dispute the duplication.
      For example, I recently had an item closed as a duplicate, so I asked, in the “original” comment stream, how my item was a duplicate and explained why I thought it was not.  I received a reply on MY original (closed duplicate) thread that, after reading my post, it was decided my post was NOT a duplicate and I was asked to test a few things and reply — but the thread remained CLOSED as a DUPLICATE.  So, no my original post was misunderstood and the “correction” left it closed while asking for an impossible reply.  This is definitely an area that could use improvement.
      * Message Entry Controls:  It is frustrating for the feedback tool and the feedback web pages to use different controls and syntax.  I have found it impossible to paste even plain text into the web message edit control (for a comment) because while editing the comment, it seems to treat the pasted text as a SINGLE WORD.  A consistent system across all forms of input collection that handles cut’n’paste operations like just about everything else that exists would be a very good start.  The GIT markdown controls are a very good example of something that could do this.

  • Chuck Ryan

    @Mads Kristensen I am sorry but we have heard all this before, or some variation of it, and we simply do not beleive it. Sure that might be your process and it might sometimes actually be followed but in the end we are right back here with someone like you writing a blog post explaining how things are going to get better. This simple fact is that since the whole Visual Studio 2012 debacle, combined with the accellerated release schedule, Visual Studio has been on a downward spiral and is often described as buggy, bloated and slow. Each new release brings more incomplete features, many poorly designed and with plentiful bugs, which further bloats and slows down the product even more… It does not make for an enjoyable day in the office.

    • Mads KristensenMicrosoft employee

      I’m sorry you feel that way. I sympathise with the perspective of this being yet another promise of things improving. That being said, we’ve already made huge strides in improving our handling of suggestions and implement one suggestion every single day now. That doesn’t mean we can’t get better, but we are actaully starting to do pretty well. I hope the blog post left you with those messages too.

      • Craig Wagner

        While I agree that the 2017 release was buggy, the accelerated release schedule (at least of “dot” releases) meant we got fixes more quickly. 2019 has been much more stable from day 1. As applications get more complex and are comprised of dozens of solutions things are going to be a little slower, so I’m okay with that.There are two areas where I feel VS does need work:1. Building a solution the first time. There’s something wrong with the dependency tracking, and when you’re running eight concurrent compiles it often gets them in the wrong order, requiring multiple passes to get the whole solution to build the first time.2. The NuGet package manager (the visual bit, not the console). It is agonizingly slow searching for upgrades, consolidations, and installed packages. There’s got to be a way to improve that.All in all, Visual Studio is still the best integrated development environment I’ve used and I appreciate the work the team puts in. My software isn’t 100% bug free, I don’t expect anyone else’s to be either.

      • Alan DeVries

        We feel this way because we are tired of being ignored. Go look at the developer community at thread after thread begging you to restore the New Project Dialog to its tree-view form. They have all been either ignored or closed with not one single positive action being taken by the Visual Studio team. We aren’t asking for minor tweaks to search; WE WANT THE TREE VIEW BACK!

    • David Williams

      I am glad to be able to say that the negativity being voiced in some of these comments does not reflect the views and experience of the entire community. We are all developers and we all know how difficult it is to produce a complex suite of software that does everything everyone wants and has zero bugs. Visual Studio has for me steadily improved since 2012 bringing features which have significantly improved my daily working life. No everything is not perfect, but a little tolerance and patience goes a long way. I regularly post feedback when I meet a pain point from using ANY Microsoft product and so far I have not been dissapointed by the attitude taken to supporting us. I for one would like to thank MS for a lot of the hard work and effort that is put in to make developers lives easier.

      • Ondřej Linhart

        How hard is to not touch anything that works and not removing existing features?

      • Matthew Polder

        I second the views of David. I have used Visual Studio since around 1995. For years Microsoft was an opaque monolith with no way to provide feedback or suggestions. With the advent of Satya Nadella and/or their declining market share things changed. Even having a way to report feedback or a suggestion directly in Visual Studio still feels revolutionary. Could the process for responding to this be improved? Certainly. But in context, things are much better.

  • Jack Bond

    You failed to mention another reason Microsoft closes a suggestion…
    Microsoft is strapped for cash.
    Yep, that’s the only logical explanation for closing this suggestion. 
    And now that it’s closed, it probably can’t be upvoted. BTW, stating, it’s a “very valid suggestion” simply throws salt in the wound. Bottom line, if you’re receiving very valid suggestions, and you don’t have time to work on them in the immediate future, HIRE MORE PEOPLE. Or is it like I said, strapped for cash?
    Finally, what is it about Microsoft programmers that EVERYWHERE you have a textbox for providing input, that’s easily going to run multiple lines, the genius responsible sets the height of the textbox to 8 pixels and not resizeable?

  • Kevin Woronuk

    One thing that I would find helpful is the ability to find an item that has the “On Roadmap” tag on the actual roadmap.  For example, this is a feature that has the “On Roadmap” tag, but I can’t find it on the roadmap and I’d really like to know where it is.  The roadmap has linkable items to the item on the developer community page, but the reverse does not appear to be true.

  • Derek Foulk

    “Close it because it didn’t get any votes and/or we’re not able to prioritize it”
    This is one my biggest issues with the way our reports are handled. It feels like too many good reports go unaddressed because they don’t get enough votes. Especially when we’re talking about stuff that only a minority of users are going notice. I’m guessing a small fraction of users are going to take the time to provide feedback. Even less are going to vote on issues that they didn’t try to report themselves. Heck, I forget to vote on issues I go to report, but somebody else has already done so.
    “Most suggestions are good suggestions and it’s always painful to close them. Especially because a lot of them are some that we personally would like to see implemented. As developers, you know that time and resources are finite, which means we can’t implement all suggestions.”
    I don’t believe anybody expects all reports to be acted on- just more of them. This is a Microsoft product that we pay good money for. Too many good reports are closed.
    If it’s a good suggestion, idea, but report- backlog that puppy! Groom that backlog, of course, but get it in!

    • David Lowndes

      Yep, voting is the aspect that gets my back up too. Suggestions/bug reports should be investigated on their own merits, not subject to a popularity contest.

      • Petr Kraus

        I have seen this process elsewhere too. And yea, I do not understand this either. Since when time prioritization is a reason for closing a ticket. I think people incorectly use ticket system as a sprint backlog. But IMO ticket should stay open as long as it is relevant\correct. Prioritization should not even enter the discussion (unless the chosen alternative path makes the ticket irrelevant). It is weird if the dev himself agrees the suggestion should be implemented at some point, but closes the ticket anyway.

  • Derek Foulk

    “Your suggestion has been queued up for prioritization. Feature suggestions are prioritized based on the value to our broader developer community and the product roadmap. We may not be able to pursue this one immediately, but we will continue to monitor it up to 90 days for community input”
    To add to my other comment… This has killed many good reports I’ve found. I feel like a lot of us give up trying to provide feedback after seeing this a few times. Especially with reports that only affect a minority of VS users (Xamarin, etc.).

    • Mads KristensenMicrosoft employee

      I agree, this is terrible wording. What it means is that the suggestion goes in the Under Review state where more votes and comments can be made. Sometimes even design iterations take place in the comments when they are Under Review

  • Daniel Smith

    Oh boy what a can of worms to open!  One thing I see a lot, is people getting frustrated that sometimes bizarre changes are made to Visual Studio, or much loved screens or features are ripped out without any requests from the community, and yet some of the highest rated user requests go ignored.
    Obviously you guys need to have the freedom to innovate, but it feels like you could make better use of the blogs to get early feedback on potential changes from a wide range of your real world users, as opposed to using private focus groups.  There’s certainly an abundance of people on here who are more than willing to provide feedback 🙂

    • Mads KristensenMicrosoft employee

      Thanks for the comment. Using the blog more proactively is a great idea to gather early feedback. Sometimes design iterations take place on the suggestion tickets themselves, but it would be more visible to do that on the blog.

      • Jakub Suchy

        Maybe you could compile list of interesting suggestions weekly and ask the community to vote on some of them with limited votes for each person every weekend. I would gladly subscribe to that!
        It reminds me something simillar to Windows 10 Bug Bash events. Except we would not hunting bugs, but suggestions. Which is in my opinion next level.

    • Chuck Ryan

      This is definitely the biggest problem with Visual Studio since 2012. Whatever plan Microsoft is following makes little to no sense to those of us who used to be considered their customers. I know we are tired of having to constantly backtrack and rewrite code because Microsoft decides to ‘upgrade’ something that works and replace it with something that removes core features and adds back nothing new. Microsoft may consider Visual Studio to be moving forward but, for all but their internal development teams, it is moving backwards as all the ‘new’ features are ignored while we constantly fight to fix what their upgrades have broken.

    • Mike Diack

      Absolutely. Witness the mess of the start/new project stuff, and the requests to not mess with the VS 2019 IDE (blue now being purple) and the menu bar etc. All of which were MOSTLY ignored.

        • Mike Diack

          Hi Mads, Credit and thanks to you for this. You’ve done a great job with this. I just tried it. Now let’s get some more of 2019 (and 2017 Update 9)’s issues addressed.

          • Tsahi Asher

            Some people just can’t accept changes. I for one did not like the 2015/2017 blue theme, and fixed it using the Color Theme Editor extension to make out of focus active tabs more distinct from the non-active tabs (e.g. when the Solution Explorer is the focused pane). This was improved in 2019. For me, Visual Studio is constantly improving, with only a few things that annoy me. One is the Help Viewer, that became optional (and with the shut down of the documents web service on old MSDN, I also can’t add custom content to it), but I know many of my colleagues don’t bother looking at API docs, and just go to Google. Another is the threat to replace SSDT with with RedGate, which fortunately didn’t materialize yet. Oh, and the old pain of removing and abandoning the Deployment Project back in 2012. So yeah, I don’t like all the changes, but there are more improvements than setbacks.

  • Alexandr Golikov

    Agreed with all above.
    What can you say about many times requested 64 bit VS suggestion that bein closed every time? 

  • Robert Gale

    Every single weekday, the Visual Studio engineering team implements a community submitted suggestion.
    I wasn’t quite sure if this is meant to be good or shockingly slow?

    • Mike Diack

      I thought the same. Given that a suggestion might be as little as tweaking an icon or writing a text message in clearer description all the way to a static analysis improvement, I dunno whether to clap or slow hand clap at 1 change per day…..

    • Vincent Thorn

      Just count: every single developer works 240 days/year. Making feature every day. (wow!) 🙂 Having even 10 developers MS could make “ideal IDE of all times” (for 15 years!). But they don’t. Too much “below the average” coders, too much “discussions” and very narrow vision of real requirements from real developers.

  • Federico Navarrete

    I’d rather focus on the bugs since the current iteration of VS2019 is quite tricky, I have experienced multiple bugs in macOS and Windows every release reaching a point that the question mark is: What is going to the new broken section? Is UWP going to work? Is Xamarin still supported?
    I’d rather focus on improving this part because I’m quite surprised that Microsoft is allowing the release of so many bugs per release, I have been using VS since the v6 to 2019 and I have never experienced so many bugs in one release in 13 years.

    • Mike Diack

      Absolutely. Both VS 2019 and VS 2017 Update 8 and later are both buggy. Please fix them before adding new features.

    • Mads KristensenMicrosoft employee

      It would be interesting to do a blog post on how we handle the community submitted bugs. We get many more bug reports than suggestions, so there’s plenty of data to dive in to.