Dogfooding revisited

In a recent post of mine on LinkedIn, I explained why it is important to use dogfooding to sell software people love to use. But what if your organization just doesn’t have the same workflows as your customers, which is often the case? This article proposes some creative and practicable ways how you can still bring dogfooding into your development process.

For those not familiar with the concept of dogfooding: it is basically when an organisation is using its own software the way end users would. The general benefits of applying dogfooding are explained elsewhere, e.g. here (and the things that could go wrong when applying dogfooding not properly as well). What I would like to stress here is that you cannot expect customers to report some issues at all. Issues that would make your product easy and fun to work with, rather than just being acceptable (see below, I find that actually quite similar to Herzberg’s 2-factor motivation theory). A big part of a good user experience would fall into this category. So if you as an organization want to sell a product people really enjoy working with, you absolutely need to apply dogfooding, I believe.

I was actually surprised that in many companies that I encountered during my professional career in the software industry, dogfooding didn’t actually happen or by far not as much as would have been possible. Even software vendors that actually sell e.g. wiki functionality would use another wiki product inside the company. Although such general purpose tools are also needed internally anyway – think of bug trackers, databases, office software etc. To analyse the reasons for that would also be interesting but that’s not my focus here. For the rest of the article I shall focus on the cases, where people say:

dogfooding – yes makes sense and would be good, of course, but we can’t apply it here because we don’t run the same business as our customers. We have totally different processes and workflows.

Yes, agreed. But maybe you can simply map labels and fields to change the semantics so they fit to something that your company needs to be doing? You could do a mapping of artifacts and with a few adaptions that software could be repurposed, so you can use it for something meaningful in your daily business? After all, in most cases it comes down to managing data via some UI form, anyway. And if your software has some localization mechanism, the labels could simply be stored in another language file and external information sources could be integrated via existing RPC interfaces.

Let me illustrate this with an example from my company. For some years, I was in charge of developing a software for accompanying and documenting missions of a rescue service. With a few tweaks I was able to use it myself as another interface to our bug tracker. I did the following principal mapping:

Original		Dogfood Mapping
mission	=>	ticket
vehicle	=>	project / software product
emergency physician / paramedic	=>	developer (or the one the issue has been assigned to)
patient	=>	the sw component to be taken care of
a relative	=>	the bug reporter

The client was in C# and thus there was already a localization system in place, well supported by the Visual Studio IDE. For the UI, all I had to do is add another language ti-et (and setup up some other master data for this instance of the system). I chose the language code ti-et, because it sounded already very much like the word ticket and I could be pretty sure that we will never have a real localisation for that language code (ti-et is supposed to stand for Tigrinya like it is spoken in Eritrea, I believe). Here is how the main start screen looked like with new missions / new tickets coming in with the new ti-et language file:

And here is what changed with the RPC interfaces to replace the control room with the bug tracker as reporting central. Before:

And with the dogfooding adoptions:

The 2 purple blocks (SOAP/plugin) needed to be created, but that’s it! Of course it came with the price of investing some extra effort, but I would say it is similar to what you have to invest in unit and integration tests for quality assurance. And it was well worth it, because now I could feel the pain of the customer in terms of usability and alike and directly take measures to relieve them from it, in the best case before the given version of the software is actually delivered to the customer.