ML 12 Apr 06

Sure these emails are silly, demanding and disrespectful, but so is posting them to the company blog.

Support emails/requests is one of the most common topics of conversation internally at 37signals. Instead of hiding behind closed doors, we’re being open about it.

Do you take a dump on the front lawn? Some things should be private, including snarky commentary about communications from customers and potential customers.

And the Gold goes to: Vyew.

Thanks for commenting here. To quote from your (actually Jason’s) final comment on the famous thread: “Everyone’s had their say.”

We agree to disagree …

We didn’t ridicule/mock our customers nor did we intend to. We used our customers own words. We quoted directly. If you feel that quoting someone directly is equivalent to mocking them…well, we disagree.

Fwiw, we don’t think the requests were stupid and we do value customer feedback. We showed theses comments so people can see the different realities that exist for individual customers vs. companies vs. the customer base as a whole.

Why share this info at all? The truth is these sorts of conversations are happening all the time in companies all over. Is it better that they be hidden from the public or is it better to have an open, honest dialogue about them?

Otherwise we’re looking at good ol’ IT command and control. And if memory serves me right, it is this attitude that gets so many projects in trouble.

I debated about whether or not to post this for two days now. My hesitation mainly derived out of fear of others potentiall…

Anita

BUT.. there is also a strong case for listening even if your initial hunch is to push back:

If you proble your clients “feature-request” a little more and engage in a discussion, because I have come to realize that behind some very specific feature requests, there often lies a deeper unaddressed issue or need which may be solved in a way that is in line with both the products direction and the users request.

For full disclosure: I am currently in the process of developing a product that is not wholly unsimilar to Basecamp (it is called AgendaPoint, and available at http://www.agendapoint.com).

I recently had a case where a user requested some radical changes to how to-do lists where managed. Now, I wasn’t going to do that, but after probing what the reasoning for his request was, I was able to find out his issue was “too many clicks” to get things done, so I was able to make him happy while keeping in line with the vision of simplicity by simply minimizing the need for clicking around.

(actually it wasn’t only “in line” with the vision, listening for the REAL issue made the product get even closer to the vision).

The moral? Do listen, but listen for their real needs, issues and objections, which may be something completely different from their initial request. But in the end, you have more to loose by not listening, than giving people the respect and time of listening to what they REALLY want.

Thanks,

Zoli