We often hear that we have to eat our own dog food, that is, try out our own products to understand how they are experienced. But I have something to break to you.
You’re not a dog.
Or as your local UX practitioner will remind you, you are not your users.
We created a prototype and rolled it out to internal users and asked for their feedback. There were three big problems with this approach:
1. Our internal users didn’t self-identify as people who were seeking a solution to this problem
After signing up, many users stopped using it not because we didn’t solve the problem for them, but because they didn’t have the problem to begin with.
We couldn’t determine if we had problem-solution fit.
2. Asking for feedback is not the same as doing internal testing
Asking internal users to test a product is totally fine. But simply asking for feedback opened us up to a company full of product designers. Tickets ranged from “we need an improved calendar interface” to “It would be cool to be able to present the meeting agenda in a slides like format….each agenda item could almost become a slide.” While these are valid opinions, we then had to manage internal expectations on what we’d actually incorporate into the product.
We were distracted with requests that sometimes deviated from the original problem we were trying to solve, and often did not address our riskiest assumptions.
3. Usage doesn’t translate to willingness to pay (or adopt)
Our employees were “highly encouraged” to use the tool, which gave us a false sense of interest and usage. To solve for this, we blocked all internal usage from mixpanel, but then we also lost the tracking for those who genuinely found value in the tool.
First we couldn’t trust our usage data, then we couldn’t even get it.
They say you can’t learn ’til you launch, but you need to truly launch. Don’t solely rely on internal feedback or solve a problem so specific you can never grow the business. If you want to see if your dog-food is any good, go to the local animal shelter and see what happens.