It has always amused me when people – usually men – say their company or team ‘eats their own dog food’. It has always struck me as a very ‘macho’ thing to say.
I’ve searched for the origin of the phrase ‘ eat your own dog food’ – there seems to be a couple of places it could have come from, but its wide spread technology industry usage dates back to 1988 in Microsoft.
Of course the point of ‘eating your own dog food’ is to demonstrate that you have confidence in your own product and can learn – and improve – from your own internal use of it.
Before I continue – let me say that I think when done correctly, using your commercial product internally can be a very powerful learning and empathy building experience.
Here are some things to consider before ‘eating your own dog food’.
Is making dog food mandatory likely to increase joyful adoption or encourage resentful compliance?
A couple of places I have seen have made ‘dog food’ mandatory. Usually the order comes from the top by someone concerned that the product has quality or user experience problems.
In my experience – how people work and the tools they use should not be made mandatory or imposed in any way. If the product solves a problem that the user has, then they’ll use it. If it doesn’t – that itself is some valuable learning. If it has to be forced then the data you get from the dog food experience may not be authentic.
Understand the risks to your business
You might argue that if your product brings a business to its knees, you would be better off experiencing that yourself first. Or not.
As much as you might not realise it – your company knows more about how your product works – or should work – than your customers. This insider information is hard to ignore.
So invariably, the product as used internally does not often cause the same effects as when used by your customers. Or if they cause the same effects – the knowledge your employees have masks the perception of the effects in a way that your customers’ users don’t.
For example – I had one customer who made security scanning software – the stuff that sits on your machine and scan files and access. Their CTO encouraged their teams to ‘eat their own dog food’ with some dire results.
Given the nature of the work they were doing, the software completely crippled any kind of software development on the employee’s machines. The order remained, except the developers – choosing to do work rather than remain frustrated – tampered with the configuration by effectively disabling it.
Not all dogs are the same – be clear which dog you are.
Sure you might be selling an email client – and you think everyone uses email the same as you do. Before you unleash dog food on your employees – make sure you know what kind of dog you are purporting to be.
Are you a small enterprise simply using email for inter company communications or are you a marketing agency for whom email is an art form? Knowing what kind of customer your company is, will help you exercise your product more comprehensively.
Also knowing what kind of user you are not reminds you not to have false faith in dog food – it is only as good as it is used. If you never exercise some parts of your product internally, you aren’t getting the early warning of how real customers might be using it.
How will you deal with what you find?
At a higher level – dog food is about feedback. Specifically getting real world usage feedback on your product from internal users.
The big question is – what are you prepared to do about it when you get it and how quickly will you do it?
This is perhaps the biggest problem I see when folk use their own products internally. More often than not, the internal users have no way of getting the broken things fixed quickly – so they continue to endure it.
Where I have seen it work well – the feedback from internal users is treated as an express lane item – because it comes earlier than feedback from external users (who typically are not on the latest versions anyway). By ‘express lane’ I mean, the triage and categorization of the feedback – i.e. urgent bug, enhancement etc – happens very quickly. Repair/remediation also happens very quickly – depending on the stack – the same day.
I’d like to share 3 handy checklists items before you commit your company to eating dog food:
- Will this critically affect our ability to run our business?
- Which customer usage do we represent?
- Are we prepared to respond quickly to what this experience will reveal?
Good luck.
