In the software world there is a term, “dogfooding,” (shortened from “eating your own dog food”) which describes the act of a team / company using the very software they build–usually as a critical part of their daily work.
That is, if you’re the GMail team and you want to produce the best GMail service you can, you want your software developers, designers, managers, etc. all using GMail on a daily basis. This will expose them to rough edges that need to be improved and the raw exposure will hasten the work to fix issues. It also serves to show confidence in the product. You might be suspicious of the quality of GMail if you heard that all the people that work on the product use something else.
This is all well and good for the kind of software that your own team can use on a daily basis. But what if your software isn’t an email client, or an instant messenger, or a music player? The software I spend my time building is not software that I have any reason to use. The customers/users are a specialized group of people.
I was having a technical discussion today with a group of software developers on this subject. We recognized that dogfooding our software didn’t make any sense in our environment, but it did make sense to sit down with our users and observe how they use the software and what seems to be confusing or slowing them down. I described this process as “wine-tasting.” We’re not consuming the product, we merely sample it in small quantities to try and understand it better.
So there you have it: if you can’t dogfood your software, you should at least by wine-tasting it.