> Former MSFTy, don’t bother wasting your time giving feedback. Nobody cares, those that cared left.
What you're describing does not comport with my experience there.
Personally, I ensured that every issue filed on GitHub was triaged (read, replied if necessary, de-duped if necessary, labeled appropriately, assigned a severity/priority) and that all feedback items from the Visual Studio feedback system that applied to my product area was either (a) de-duped to GitHub and given the same treatment, or (b) dealt with in that system because it might have had some info that could constitute private data being leaked (sometimes I'd create a representative issue on GitHub and de-dupe to that one if appropriate).
What I'm describing is actually routine for most PMs and engineers in the group I was in, and that's still the case today. I won't claim that it's perfect or that everyone who files an issue will have their bugs dealt with immediately, but I've had several community members give positive feedback about the whole thing and talk about how it's like night and day compared to previous eras at the company.
> Even for software where ‘zero bugs’ was important they’d just delete a whole bunch of bugs and see if any bounce (come back). Eventually people get sick of refilling so they get to zero but bounce by exhausting the very people eying time help them.
This is ridiculous and I sincerely hope it's not happening outside of small groups (who should stop right now). I never saw this happen. We'd deprecate some older things and then close associated bugs as not applicable, but declaring bankruptcy on a bunch of legit bugs would be unheard of in the group I worked with. If you were caught doing that you'd be in some deep shit, since it's a violation of the trust your community places in you to be a responsible caretaker of the software they rely on.
> Enough social media pressure may end up risking a line item in a PMs yearly goals.
Social media pressure is a thing, sadly, but also not that much of a thing. Only in rare cases did something exploding on twitter or whatever cause action on our end. I'm also curious where in Microsoft a single PM's line items are treated with that much relative importance. This whole notion of "PMs dictate and devs make it happen" is bizarre to me because figuring out what to do next was always a collaboration and careful evaluation of tradeoffs across both disciplines. Again, it wasn't perfect and there's much I wish was different, but fundamentally it was sound and constructive. Any of my line items as a PM wouldn't somehow get re-prioritized just because someone yelled about it on social media.
Anyways, I'm sorry you had a bad time with what seems like it may have been a bad group. If what you're saying is true, I hope that changes for the group you were with.
Hi Phillip, you are a very unusual PM in a very unusual group that is able to derive a lot of value from user feedback who are usually very technical experts. I'm not sure how much your personal experience generalizes. Same could be said for my experience I guess so that is a fair point. I definitely had a bad time at a bad group. In the Steves era there were a lot of bad groups. I predate your tenure by quite a bit but I do keep in touch with former colleagues and exert soft influence to get the things I need built. I also think there is a selection criteria bias on the type of PM to be on HackerNews. Why does it happen to be you posting here out of such a large company. Also I thought you left - I would have counted you as one of the ones who cared leaving? I know others who also care haven't left but I think it's safe to say that on average they care less. You will be missed. You also started at MSFT right? I think you're taking things from Microsoft on face value that perhaps you shouldn't be.
Eh, not too unusual! Not everyone is the same, but the care factor is high for my previous peers, most of whom are still there. I can also appreciate that for consumer tech things are different. There is a higher degree of "it just needs to work" because it's unlikely the average user can articulate what's wrong, and they shouldn't need to anyways.
One thing I'll say is that it really does feel like the worst decisions about software there were made during the Steve Ballmer era. In my case, trying to keep compatibility with absolutely insane software behavior where it tries to do way more than it reasonably should made up the bulk of my toil and issues customers had.
A former coworker described to me that it was a very different time then. People believed they were the best engineers in the world, building software nobody else could make. In some small cases maybe that was true, but generally it was not. The combination of arrogance and willingness to try to bolt on as many capabilities and unbound extensibility features as possible led to a severe problem for people (sometimes the same people!) later on in life. It's actually been cool seeing how that complexity was methodically tamed. But it also makes me fear for any future company where a similar level of arrogance is practiced.
Again, you were in a very unusual group. I agree you have peers that do care a lot, my statement was hyperbole, I didn't literally mean that no-one cares. One must also weigh the caring by those with the ability to effect change. Microsoft is still a very top down org so you have to look a Julia Liuson and Scott Guthrie to get an idea of what will happen. AFAIK both of them respect Don Syme enough to provide political coverage for you and your colleagues so that you all could focus more on your jobs instead of office politics. But I feel that neither will fund F# enough to unleash it's potential. Visual Studio has stupid F# bugs and AFAIK they won't get fixed. And really, leaning on the constantly breaking 3rd party open source plugin Ionide for F# VS Code support. I know people on the F# team (again an unusual team) care about it but Microsoft as an org doesn't care enough. And not to mention the dogs breakfast that is Win11.
This is my experience as well. I am a PM in Edge team and we take user feedback in our app extremely seriously. There are entire teams which parse the user feedback and add bugs for them. All top feedback is expected to be fixed under a specific SLA and these metrics are often tracked at leadership level.
In fact, for a lot of feature teams fixing the top user feedback issues is often part of their OKRs.
So yeah, I don't know if there are groups in MS which really don't consider their users' feedback, but from what I know that isn't the common behavior.
MS has its faults - every megacorp will have its own share of warts, but this specific one, i am not sure I can believe.
Excuse me for the (unusually for me) negative attitude and ranting, but I for one would never even think about posting feedback to edge as it so aggressively user-hostile that I would never believe UX matter at all to anyone on board. Even the most common use case - downloading chrome - is a painful experience, which the browser serving you with tears all the way. Opening edge for the first time throws chain of undesired bold messages and then the NSFW msn.com.
Sometimes I have to open edge on multiple costumer servers, with new user profile in each of them and with no customization of the defaults in place. Terrible experience, multiple clicks to do what you came for in the first place, and then again serving you the delightful and stylish MSN homepage,
As someone _making_ those user feedbacks as an employee of MSFT, I've never felt heard nor taken seriously. Apathy from users is unfortunately earned by experiences. I'm glad your experiences have been better, and don't mean to generalize my experiences. I am however providing another datapoint.
I guess the difference is that Microsoft actually has to compete for people to use Edge, whereas other products people are just forced to use by their employer like that dumpster fire that is Teams.
Issues filed on GitHub != process that goes through the Windows Feedback Hub. The latter is a completely opaque process and product team engagement varies wildly from feature area to feature area.
What you're describing does not comport with my experience there.
Personally, I ensured that every issue filed on GitHub was triaged (read, replied if necessary, de-duped if necessary, labeled appropriately, assigned a severity/priority) and that all feedback items from the Visual Studio feedback system that applied to my product area was either (a) de-duped to GitHub and given the same treatment, or (b) dealt with in that system because it might have had some info that could constitute private data being leaked (sometimes I'd create a representative issue on GitHub and de-dupe to that one if appropriate).
What I'm describing is actually routine for most PMs and engineers in the group I was in, and that's still the case today. I won't claim that it's perfect or that everyone who files an issue will have their bugs dealt with immediately, but I've had several community members give positive feedback about the whole thing and talk about how it's like night and day compared to previous eras at the company.
> Even for software where ‘zero bugs’ was important they’d just delete a whole bunch of bugs and see if any bounce (come back). Eventually people get sick of refilling so they get to zero but bounce by exhausting the very people eying time help them.
This is ridiculous and I sincerely hope it's not happening outside of small groups (who should stop right now). I never saw this happen. We'd deprecate some older things and then close associated bugs as not applicable, but declaring bankruptcy on a bunch of legit bugs would be unheard of in the group I worked with. If you were caught doing that you'd be in some deep shit, since it's a violation of the trust your community places in you to be a responsible caretaker of the software they rely on.
> Enough social media pressure may end up risking a line item in a PMs yearly goals.
Social media pressure is a thing, sadly, but also not that much of a thing. Only in rare cases did something exploding on twitter or whatever cause action on our end. I'm also curious where in Microsoft a single PM's line items are treated with that much relative importance. This whole notion of "PMs dictate and devs make it happen" is bizarre to me because figuring out what to do next was always a collaboration and careful evaluation of tradeoffs across both disciplines. Again, it wasn't perfect and there's much I wish was different, but fundamentally it was sound and constructive. Any of my line items as a PM wouldn't somehow get re-prioritized just because someone yelled about it on social media.
Anyways, I'm sorry you had a bad time with what seems like it may have been a bad group. If what you're saying is true, I hope that changes for the group you were with.