Before coming to Fog Creek Software, I never had to think about who my customers were. When I was working as a consultant, my customer was the client that was paying the bills; if they wanted a feature and were willing to pay for the development, then that's what I did. When I was developing prototype software for a research group, my customers were the scientists; if they needed software to acquire data, analyze data, or control equipment, then I would build it for them. There was never any question about who I should be listening to, because they were real people that I interacted with daily.

Things are different in the software product world. FogBugz has thousands of existing customers and many more potential customers. And each of those customers uses FogBugz in a slightly different way. Some customers use FogBugz as:

• A simple bug tracker
• A help desk to manage customer support
• Project management software
• Support forum software
• All of the above and then some, as we do here

Because of the multitude of ways in which FogBugz is used by our customers, defining what the "customer" wants can be extremely difficult. When I was a consultant, I could just ask the client to find out what feature I should implement next. Because there was a single voice to listen to, my decisions were easy.

When there are thousands of voices, feature decisions become much harder to make.

• Do we ask for a majority vote on each feature?
• Do we pick features that will make many of our customers a little happier?
• Do we pick features that will make a minority of our customers a lot happier?
• Do we trust our own design judgment on which features will work well together?

In the end, we do what we think will make our customers in aggregate happiest and most productive. Unfortunately, because we have limited resources, we can't do everything. When we don't implement a customer's feature request in a given release, they are disappointed, as if we were a consultant that failed to deliver what was promised.

To some extent, that's a consequence of our customer service ideals. When you call us, a capable person picks up the phone and is able to help you do what you want. We respond to all emails personally within one business day, and regularly respond on our discussion boards. That level of personal interaction raises the expectations of our customers that we are serving them directly. So when our software fails to deliver what they personally need, we are failing to live up to our own lofty standards.

What our customers can't see is that we live up to those standards internally. When we are doing triage for a release, we have customer advocates arguing for each of the features, and we have long discussions to balance all of the factors discussed above. Unfortunately, some features will always have to get postponed (but still kept in FogBugz to be considered for the next release). 

Making a software product is hard. I had it much easier when I worked as a consultant with only one voice to satisfy, but the flip side was that I could only make one company better with the software I wrote. FogBugz makes thousands of companies better at once, which makes it worth sorting through all of those voices to decide what should be implemented next.