The term “Dogfooding” means allowing employees to test their company’s products in real-life situations with their employees — before its actual launch with the consumers.
It’s been in practice with the Product and Service companies for long. The practice is easily justified as companies, big or small point a finger at the budget spreadsheet which doesn’t have a column for User Testing. Plus look at the time! Deadlines always happen in yesterdays. So, the easiest bet to tick that checkbox for UAT testing would be test the product on their own stuff, often at times when they are at a raw stage. So far so good, right? Talk about early stage feedback, eh!
Let’s see why allowing the employees an early access to their yet-to-be-launched products or “Dogfooding” in industry terms is benefiting or damaging.
Jared Spool noted that, when a team inside an organization designing and building a product for themselves test their own product/application, they often tend to improve the tasks that they frequently use and ignore tasks they believe are less important. The most common task being neglected is, the on-boarding task for a new user. On-boarding becomes the least priority of intranet applications when it goes through the “dogfooding” process. The inside testers often think, everyone does this once and once only, and commonly fails to highlight any opportunities to improve it.
Ignoring your on-boarding is equivalent to inviting a list of elite guests to your house without cleaning up the stinky garbage at your doorstep. You may wonder what’s wrong with the 30-course menu on table and why only a handful of the invitees have turned up, but the real problem lies at the gate.
Let me tell you the story of a company which spent hundreds of thousands of dollars in building a HR portal. It was already being tested by their 50K+ employees so it’s time to package and sell, they thought. So, they set out a course, on-boarded designers, developers, support people, marketeers and sales rep. At the end of a year-long campaign, only 2 companies showed interest and one of them backed away. I will tell you what went wrong and perhaps this will sound familiar to you.
It all started when the company was small, they purchased a product, customized and added features after feature over years and now a solid 50K+ users are using it. What can possibly go wrong? Obviously, this is an IT company I am talking about and presumably everybody around here are faster on keyboard and screen than other Industries.
So, to get feedback of the users, the developers implemented a feedback system, a rating system and encouraged the users to rate the apps inside the portal and give their feedback. Regular emailers were sent, reminders on top of that reminding users to use the new feature, analytics were implemented, and system processing speed were improved. Few good feedbacks came along the way and the creators of the product were satisfied and made few bug fixes and improvised on the user feedback. This went on for about a year, plenty of time to build features on top of an already popular and most importantly stable system which has been running smooth for years!
Now let’s talk about why ‘dogfooding’ failed in this scenario. And the product didn’t perform well as the company anticipated here?
1. Poor On-boarding Communications comes at a price.
Mentioned this already, but let’s dive deeper. On-boarding is a once in a lifetime event. “Dogfooding” scores poorly because a lot of folks who are testing already know how the system works, even if they see a new design, most likely they already performed the task and probably be looking or expecting the same behavior in the new system. The only obstacle that’s coming in their way is findability of their desired action button. They are no way in a position to understand the pain of a real user who might be joining in the organization or might be shifting from another industry.
A small improvement in the on-boarding process can make a huge impact on the users. An assured employee, who knows where stuff resides can be much more productive from Day1 than a confused newcomer taking weeks to figure out how stuff works. If your organization recruits 50 new employees a year, it can cost the company a combined loss of almost 1-year worth of productive time wasted by the newcomers. The figures may be rough, but you get the point! Also, in jobs where intranet being used as a tool for decisioning (like call centers, mortgage/loan industries, membership application processing centers), a small mistake in decisioning can cost the organization $ and reputation.
2. No feedback isn’t always good feedback!
Most users doesn’t have the patience for feedback. Especially if they must look for a place to give feedback. When they are coming to perform a task, they leave after the task is complete. Their silence should not be taken as an approval. Many users, unless forced (by the power of authority or obligation) doesn’t feel the necessity to give feedback. Developers think feedback is bad and no news is good news. Some users remain frustrated forever, but they just don’t feel like giving feedback.
3. Long Documentations and screenshots don’t work.
The new system is launched with lots of help material. Screenshots, FAQ, Documentation. Everybody is pleased. Now think of it, when was the last time you read the document when you hit a wall while performing a task? In context chat or Call button is an excellent way to handhold. If you really want to aim for the moon, don’t have any Help Material on the site. Help section for a design is like an explanation after a Joke. If you are to be told where to laugh, it’s not a joke anymore.
4. “Take your time to test” isn’t always the best way to validate.
In any organization, people when given an additional task not related to their daily task will deprioritize the task and no KRA for their effort will put the task into back-burner. If you are assigning your employees a task to test and validate your design, you are essentially eating up their free time. You think it’s causal, no real pressure, they can do the testing while watching football. Let me assure you, it doesn’t happen that way! A half-attentive user will give you incomplete and perhaps vague feedback. You might some good input here and there but in most cases, they will fail to point out something very important because they are paying less or no attention. Without a recognition or a bounty for their effort, they will go from point A to B but will not be exploring the surroundings that you want to show them.
5. Employees aren’t always honest when it comes to giving feedback.
Even if you receive some good insights, most employees become very conscious while giving feedback developed by their employer. Sometimes they try to assess the impact of their feedback. Fear of being in a bad book and fear looking like a fool by their seniors often constraint their thinking. As a result, the feedback that you get, are not totally honest and often, influenced by fear.
If it’s a product or application for varied geography, perhaps you are ignoring culture, context, religion and many other human emotions. On the other hand, real users, when assured that their feedback will influence to make a difference, will give away their frustrations and failures more easily. Also, they will add socio-cultural aspect to the feedback which will add value to their feedback. One thing sure to be mentioned that these real users must be assured and re-assured that their failure to perform a task will not be judged as their failure, but the design’s and their input will act as an improvisation tool to improve the design.
Hope you have found this article interesting and familiar. I would love to hear your feedback, comment and opinion on “Dogfooding”. Please feel free to drop a note here.
Core Intensity 