Tech-Ed Notes on the MSDN Product Feedback Center
More notes from Tech-Ed. This time its what I heard about the Product Feedback Center experience.
Forced Search First
“Its tough to find bugs for dupes. The search needs a lot of work. Right now it feels like a wasted step for people who file a lot of bugs”
“Maybe you stop the forced search once someone has entered enough validated bugs”
“I don’t understand the categories or where to put the bugs”
This is great for first timers, but really bad for your best contributors. The consensus seemed to be that we should find a smart way to let good bug finders loose on the system and trust them to do the right thing. Suggested bugs shown on the bug entry UI would be acceptable still.
“I couldn't find an escalation path to complain about my response and I’m hesitant to re-open the bugs. I just wanted more information about the response I got, but I understood the resolution”
“Its excellent when you get a good reply even if its not the reply you wanted to hear”
“replies (initial) in 2-3 days is optimal and under 7 is good enough. Anything more than a week would be bad. I would have given up”
“ I noticed that the time to response varies greatly depending on where you are in the product cycle”
“It would be great if the feedback site explained more about the product cycle current timing to set response time and chances my bug will be fixed expectations”
“Why don’t you put the current expected wait for replies and recent bug fix % on the site to set expectations?”
"If something is postponed I want to always know when it has been postponed until"
"If something is fixed I want to know when I can get the fix"
"What the hell does 'by design' mean? Whose design was it? Why is it the design?"
Our responses; the time to, quality of, etc have the ability to completely color the experience above any of the end results. Users really liked the idea of an escalation path if they felt they got a lame response that didn't involve re-opening the bug. One person asked if we moderated all the replies that go to customers. When I said no, he asked why not? That's how important users seemed to feel our responses where.
Post Whidbey RTM
“A lot of people are frustrated with reporting VS 2003 bugs./ I hope you don’t turn this off for VS 2005 once it ships and you do something with the bugs”
“there really needs to be more emphasis on putting these bugs into service packs for the product after you ship”
I think we ultimately need to be very clear and upfront with customers that file bugs after we ship whidbey about what we are going to do with those bugs. It goes back to the importance of the response that I called out above. It was hard to get the conversation back on topic once the issue of product servicing was brought up. I'll go back to this in my notes about MS perception.
- “I really like that other people can vote. This tells me if I’m crazy or not when I open a bug”
There were more than this, but I can only write so fast. The fact that you could see and vote on other peoples bugs (and that they could vote on yours) was considered an important success factor because its a lot easier to understand fix % if you see a line of bugs with more votes than yours ahead of you.
Again, there were lots more quotes, but most of them fell into the basic themes captures above. Next time I need to get a dedicated note taker for these sessions.