Question

So why so many choices? And what's the difference between all these choices of support? Which is better or more helpful? Which is preferred by Fog Creek or preferred by customers? Are there pros and cons to each choice?

Answer 1

In the 18 months or so that I've been in charge of aggregating customer feedback, this is the process that has evolved to capture every bit of value possible out of your call or email or discussion post:

Whether you call, email, or post to the discussion boards, a case gets created.

That case represents the work of making you happy (or at least informed). Any work beyond making you happy is spawned into a related case. This includes bug reports and features. But there's a whole class of other stuff that we're not really sure what it is yet. It could be a feature in search of a compelling use case. It could be a blog post needs to be written, or we need to rethink an error message. It could be just a hunch that we didn't need to have this customer call in the first place. We call these cases "Fix It Twice" cases, and they represent the other half of the job of supporting great software. I would also argue that they represent the lion's share of creating a rewarding software support job.

The phrase "Fix It Twice" sometimes confuses people I've talked to outside the company, so I'll just say it's from this article. It's not a new concept. It just means fixing the root cause of everything you can. I haven't encountered a support organization that doesn't espouse this ideal. Until Fog Creek, I hadn't even heard of one that did much more than pay lip service to the ideal.

Here's how we actually do it:

Once I get caught up with making sure everyone's happy and informed, I block off a chunk of time (like now) for strategic work that you just can't do while you're doing queue-based work. It's too mentally "chunky." The first part of that is going through my backlog of "Fix It Twice" cases.

A "Fix It Twice" case can go several places:

• Bug Report. If a case has an easy replication, we generally don't delay filing it, but if we need to set up a special environment or if the bug is non-urgent, it can end up in "Fix It Twice".
• Feature Request. Again, if a feature request was clear, it would just go right to the program manager. If it seemed possible to construct a workaround or it just needed a compelling use case, it'll end up here.
• Bad Penny. These are the questions that just come up again and again. It's usually something we have a reason for not having in our future plans.
• Potential Change. The breadth of customer desires is huge. Everyone wants something different. We've been using the Potential Changes area to store good ideas from our customers.

For the latter two, we have an ad hoc voting system. I put the case in the right area at priority 6, then periodically sweep through them and close dupes, raising priority as I do, so the most frequent requests bubble to the top.

This method has been a barely adequate way of keeping track of the things that people want, and the confusions that they have. It is vastly inferior to what Stack Exchange is poised to become. I'm happy to have a place to put these now, and happy to have spent 18 months aggregating this feedback so it can be poured back into StackExchange... which is what I'm doing as I get the chance.

I am pushing through my Bad Pennies and Potential Changes to get them out into the air of StackExchange. My system was never a way to squelch debate on a topic, but to glean as much value out of incoming customer contacts as possible. I'm excited to see where things go from here.

Incidentally, the number of "Fix It Twice" cases open is a very good proxy for my job satisfaction. If I'm keeping that number low, I'm communicating to the rest of Fog Creek what our customers are talking about. Support people don't thrive on answering the queue or even troubleshooting tricky problems. They thrive on controlling their environment, the same way anyone does. Turning "Fix It Twice" cases into customer intelligence and strategic insight is what support does at Fog Creek. It's our primary function. Making our awesome customers happy is just a side effect, albeit a good one.

Answer 2

I think if I request a feature using the web form then it will go directly to a Fog Creek employee's inbox and they will pretty much have to decide right then and there whether to implement it or not. I consider this a CON because it's harder for little ole me to justify my feature request directly to this one software developer.

But I have a feeling that if I request a feature on the stackexchange site where many other users could see my request and possibly vote it up, then the Fog Creek employee will not only see my feature request, but they will also see all the other users who agree that it is a good thing to implement and there might also be some good discussion on the topic, and in my mind this will be harder for the Fog Creek developer to turn down the feature request.