Listen To Your Users

by john on March 19, 2003

If you are a software developer, either for internal or external customers, it is absolutely critical that you maintain a solid bug/feature-request database and that you build closed loop processes around your users who make the requests and your developers who deliver the solutions. The most important thing you must do, however, is let your customers know you are listening to them and reward them by actually making the improvements they ask for. Showing that you are listening and most importantly responding is unusual and powerful and will result in better solutions.

This point was hammered home to me a number of years ago when I was involved with a CRM application implementation. One of the first things I realized was that we were not getting enough feedback from our user community on what was working and what was not and to resolve that we created a “Feedback Button” that appeared on every screen within the application. We educated the users on what it was for and how to use it and we made it very simple so that all the user had to do was pretty much click the button and make a comment. Behind the scenes we captured a lot of metadata about what the user had been looking at when they pressed the button, which provided the context we often needed to understand the issue.

When we first offered this feature I actually had to bribe the users to take the time to enter comments. I would give away Amazon.com gift certificates to random drawings of people who had submitted feedback. I cajoled; hell I probably even threatened. But then a funny thing happened – we started getting a lot of feedback without that. In fact before long I didn’t have to ask for it anymore it just came, and it began to come from many different people throughout the organization. Some people didn’t go a day without hitting that button.

What happened? Very simple.

The users learned that the developers were listening to their feedback and actually making changes based on it! The time they spent documenting their feedback suddenly was well worth it because it resulted in changes that they benefited from.

I’ve been reminded of this story a number of times over the past few weeks.

Dmitry Jemerov, the developer of Syndirella, writes in his weblog about a change in his personal policy for addressing bug reports:

Looks like my initial policy for answering bugreports – “as soon as a new build is released, go through the entire archive of unanswered e-mails, find the ones that reported bugs fixed in the new build, answer and tell them where to download the new build” – has failed miserably, which should be quite expected.

Dmitry’s answer is to ensure that every bugreport gets logged and the user notified. That’s a great first step. Close that loop by reporting back to them when a decision has been made regarding the bug, either that you won’t be fixing it (or more likely, adding that feature request) or you will be, and by the way here are the updated files. That would be huge.

Dave Hyatt, one of the Webcore developers for Apple’s Safari browser, has been maintaining a weblog throughout the beta period and has been very open about addressing problems that users have been presenting, and actually responding to that in the public forum of his weblog. Most impressively, many of these reports have already resulted in changes in the application. Here is an example of Dave’s open style:

Tantek blogs about how Safari messes up his CSS presentation slides. The bug actually is with the following:
<style media=”print”>…
Safari is forgetting to cache the media type it observed on the style attribute. It doesn’t have this problem with link elements, just with style elements. Since your print sheet sets all the slides to be visible and hides the footer, that’s what causes all the madness.
FWIW, this is issue #5 under “CSS Importing Bugs” on diveintomark’s list. It is now fixed.

Dave acknowledges a bug, identifies some people who have reported it, and has let us know that it has been resolved. Simple. Brilliant. Encourages people to try even harder to find problems. Free QA. Better product. Did I say Simple & Brilliant?

Scott Johnson has been working overtime the last couple of weeks bringing out Feedster (née Roogle). He’s also been publicly mentioning the users who have provided him any level of help.And I do mean any. My minimal contribution earned a mention:

John over at John’s Jottings for helping with some important edits and for pointing out this really good CVS basics stuff from Aaron

But you know what? I’m now more likely to pay closer attention to Feedster and mention something again. In fact I did. You start multiplying that by tens of people and you start to see the picture.

Release early. Listen to your users. Respond to your users. Release again. Lather, rinse, repeat.

{ 1 comment }

Joe Grossberg March 20, 2003 at 10:26 am

Well, I have one caveat (with Bugzilla, at least. FogBugz, for example, may address this):

You don’t want the public to see every bit of back-and-forth between developers that you have documented.

Examples:
* unaddressed security holes in the current release
* details of the source code if the project isn’t “open”
* candor among programmers
* assessment of how (un-)important a particular bug is
* etc.

That said, I wholeheartedly agree with your basic statment that “it is absolutely critical that you maintain a solid bug/feature-request database”.

It’s one of those things, like version control, that I don’t know how I ever lived without.

Previous post:

Next post: