Eating Dog Food?
I’m not sure how many of you have heard the phrase, “we eat our own dog food,” but for several years at least, companies especially in Silicon Valley have used this phrase in order to impress their customers that their product is so good that they run their business on it and use it themselves. This was practically a mantra at Netscape, and I can’t count how many times I’ve said this myself.
Today, I’m embarrassed to have said something so meaningless. Of course we used our own products. It would have said much more about the state of our products if we couldn’t use them. And yes, of course you should use your own products, but you need to realize that it’s just another form of QA. Just as you wouldn’t brag that your software passes unit testing, you don’t need to brag that you can actually use it.
But the real issue here is not the importance of running your own software. The real issue is that this is just another symptom of a big problem we have in our industry, but especially here in the valley. We tend to believe that our customers and users are much more like ourselves than they really are.
If we like it, and we can figure it out, then others will too. The problem is that this just isn’t true. Yes, there are some niche markets like developer tools where it is somewhat true, but even there it’s less true than you may think. There are several reasons for this.
First, realize that not only do you not have to pay for your own software, but in fact you are paid to use it, as employees. It would shock me if SAP doesn’t use their own software to run their business, but it means nothing to me that they do. Their employees essentially have a blank check to make it successful. But their customers don’t. Imagine the SAP employee struggling with the product, and getting to the point where he says to his manager he wants to switch to Workday. Do you think that’s likely to happen? Of course not. But do you think this could happen at their customer’s site. It can and is happening.
Realize that your company’s employees are much more vested in your product and company than your customers, and that means you’ll tolerate more, much more than your customers.
Second, if we have a problem or a question, we can just go ask the developers. Your customers can’t. They have to read manuals, attend training classes, sit on phone calls with customer service, or sift through forums with other customers struggling through their own issues. Frustrating and time-consuming, and detracting them from whatever their real job is.
Third, a great many of us in tech companies are early adopters by nature. I know I am, and I also know that this means that what motivates me is going to be very different than what motivates target customers. This is a big reason why I like personas as a tool for calling this out.
But the bottom line is that all this points to how absolutely critical it is to test your ideas and your product on real target users and customers. If you haven’t been surprised by how different a customer’s response to your product is, then you probably haven’t yet done this type of testing.
Remember also that when you do this testing, it’s not enough just to get your product to the point where the user can figure out how to use it. You also have to get the product to the point where the user chooses to use it.