Understanding the Feedback Process

During the development of any product, the vision for the upcoming release is driven by the desire to help as many customers in the most effective way possible.

One of the interesting aspects of a release is balancing the effort you spend on different aspects of that project:

  • New features and broad changes designed to address significantly new customer scenarios.
  • Feature updates and incremental changes designed to improve scenarios already (or partially) addressed by existing features.
  • Bug fixes designed to address functionality that doesn’t work as designed.

When weighing these factors, a critical factor is customer importance. Aggregate customer needs (and user research) heavily influence the first bucket, so the customer impact there is clear. The second two buckets come by way of direct customer feedback and bug submissions: http://connect.microsoft.com/powershell and pose a more difficult problem.

When looking at a piece of feedback in isolation, the customer impact is difficult to judge. While it is clear that the original feedback submitter ran into the problem, are they the only one to have run into it? Clearly, bugs and feedback that have broad customer impact are easy decisions to make when your goal is maximum value for the customer. Conversely, bugs and feedback that have little customer impact shouldn’t disrupt the features, feedback items, and bug fixes that do.

We’ve updated our Connect site to make this process as clear as possible:


If you are impacted by an issue, following those directions is the most constructive way to make your feedback known.

The key point here is that customer impact drives our decisions. You are the key for helping us determine customer impact. A vote for an existing bug or feature request is just as impactful (if not more!) than the original submission.

If you are impacted by an issue or have a suggestion, please visit http://connect.microsoft.com/PowerShell.

Lee Holmes [MSFT]