Eat Your Own Dogfood

When building or maintaining a system, you need to spend some effort to make sure that the pain points of that system are felt by the development team. I thought that this was obvious, but I have spoken to enough developers to know that it just isn't so. I would like to say that this is an original thought, but my foundation is a paper I read while working for Wachovia Bank in the mid 1990's. I was browsing the intranet one day at work and ran across a paper written by one of the IT team. (At the time, I though those guys were mysterious wizards in a far off building doing arcane and magical things. I still think this.)

When developing or maintaining a complex system, it is human nature for those who are doing the developing and maintaining to focus on the system itself. To work toward optimizing the system, making sure that the parts of the system are harmonious. This goes so far that the users of the system are seen as distractions, at best, or malignant actors, at worst. You might be too young to know about the adventures of the BOFH (Bastard Operator From Hell), but it was very entertaining for system administrators to read back in the day.

But the WHOLE POINT of the SYSTEM is to SUPPORT USERS, and if the system is not accomplishing this goal, it is a useless system. Let me be clear, a 'user' and a 'customer' are interchangeable here and anyone who uses your system is a customer. Customers can be external users in a B2C context, B2B context, or users within your own organization. As a developer, you are always writing software for a customer.

So, to pivot your system to helping users, you have to know what problems and difficulties they are experiencing when using your software. And only a small percentage of users will tell you what they do not like or offer suggestions for improvements. To understand what works and does not work in your system, you need to be a user of your system. You make it, you need to use it. If you cannot do that, you need to have your developers close to your users. That could be a physical 'close' or it could be a direct way for users to easily communicate with your developers. Developers need to feel the pain, they need to eat the dog food they are making so that they can more clearly understand where the pain points are and how their work affects the lives of users. This helps in the following ways:

• Shortens the feedback loop to keep development goals aligned with user goals.
• Keeps changes relevant to users and grounded in practicality.
• Improves customer engagement and, if handled correctly, increases customer loyalty.
• Makes development team more cautious about making big changes that might 'break' user expectations or experience.
• Makes the development team aware of the side effects of changes.

Well, Richard, if this is so all-fired fantastic, why don't more development teams practice this?

• "Constant interruptions will slow down development!" Which is true, but if the last thing you built is breaking to the point where users are complaining, you need to fix it before moving on to the Next Big Thing.
• "Users don't know what they want or want crazy things that won't be an improvement!" Which you could effectively discuss if you knew what they were doing with the software and could say that you were working to address their pain points effectively (because you feel them, too).
• "This will blow up my scheduling!" Which means that your scheduling is too ambitious or rooted in a "systems" frame of mind instead of dealing with practical problems. If the schedule is important, you know what problems the schedule is addressing and can effectively set user expectations. "The change we are working on will do X, Y, Z and that means we won't get to your thing until next week." Has a hell of a lot more weight if you can honestly say your understand the problems they are experiencing first-hand.

I feel like I could go on there, but those are the biggies. Software development, especially in an organizational context, requires that the distance between the developer and the user be as short as possible. If you can engineer that distance to be zero, you are going to achieve better outcomes and higher customer satisfaction more quickly than any other 'fix' will be able to provide.