|||
This is a letter I wrote while working on an innovation team at Zendesk. Our head of design skimmed it, which is something. I still feel strongly about the power of eating your own dogfood. Maybe you do too.
I normally don’t listen to real estate agents, but Gary Keller (of Keller Williams fame) wrote a book called The One Thing that changed my life.
You don’t have to buy the book (sorry Gary), because here it is in a nutshell:
We don’t eat our own dogfood. Because we don’t eat our own dogfood, we are unable to empathize with our customers. And because of that we cannot (and generally don’t) design effective solutions to our customers’ problems.
Eating your own dog food or “dogfooding” is the practice of using one’s own products or services. This can be a way for an organization to test its products in real-world usage… dogfooding can act as quality control, and eventually a kind of testimonial advertising.Wikipedia
“Eat our own dogfood” means, we use our product like customers would use it. We say we eat our own dogfood, but only our customer service department does. I can certainly speak for designers when I say we don’t use it. I don’t think engineer or product managers do either. At least not in any serious way.
Not dogfooding costs us money:
If we don’t use our own product, why would our customer?
“Our product isn’t good enough” is not a good reason not to do this. If anything, it’s the primary reason we should do it.
But the main reason is we might learn something.
Because we don’t dogfood, we don’t know our own product as well as our customers do. Kinda goofy right?
This is especially true of designers. If you don’t understand your customer, you will have to do this:
This is painful for employees and customers. I don’t like pain, nor do I like doling out pain. Do you?
I once heard an executive on a call say, we don’t eat dogfood we “drink our own Champagne” and that kind of chucklefuckery is part of the problem. “Eating your own dogfood” isn’t supposed to be bubbly, celebratory, or fun.
Dogfooding is kind of painful (like working out or pretending to enjoy Verdi). You’re using a half-ready product that you’re building at the same time. It’s like living on a construction site.
It’s tough.
Want to know what a marathon feels like? Here’s how:
We are stuck in a cycle of fiending for UX research, ignoring everything we learn, building what we want, being confused about what we build, demanding more user research, ignoring everything we learn… and so on.
But even if we tripled our UX research resources, reading a deck of user insights doesn’t equal empathy.
That expression, “walk a mile in their moccasins” comes from a beautiful poem called Judge Softly written in 1895.
Just walk a mile in his moccasins
Before you abuse, criticize and accuse.
If just for one hour, you could find a way
To see through his eyes, instead of your own muse. Mary Lathrap
You’ll note that it’s not “walk around the room” it’s “walk a mile.” Like a lot of designers in this industry, we have become too reliant on our own muse.
You don’t build empathy by just reading about something, once, in a already-forgotten deck, while multitasking. You don’t learn how our product works by spending all day in Figma. You don’t understand our users just because you talk to them occasionally on a Zoom call.
The problem with asking people “what problems do you have with our product” is that users’ answers are infected with three kinds of bias:
Humans can only talk about problems they know how to talk about. They are not user experience experts or software people, they are experts in their own domain. They won’t ever say: this is the experience problem and here is the root cause and here’s a way to build it that allows you to side step tech debt. More than likely they will mention a vague symptom. We rarely dig into these, we just take the first answer and build.
If you have 40 minutes with a research participant their responses will skew toward problems that are more salient to them, and seem to them, worth mentioning. They will self-select the bigger problems (that they know how to articulate, see above). But other problems can add up to a tremendous amount of pain, and sometimes, these smaller problems are indicators of something deeper. And might add up to a whole feature or product!
From Henry Ford’s famous dictum: “If I had asked people what they wanted, they would have said faster horses.”
If you ask customers what they want, they will take the solution set for granted (because why wouldn’t they) and simply try to modify it, usually in the upward direction. “Views are great, I wish I could have more.” They probably won’t say: “It would be nice if you could use a machine learning algorithm to predict which tickets are most-suited to which agents, obviating the need for shared queues we all draw down from.”
I believe dogfooding a product makes you a better designer of that product for the following reasons.
We gain intimate context. We see our product from the perspective of our customers. We feel exactly what they feel. This means, when a customer says, “I find that changing my user status is finicky” we have a physical sense of what “finicky” means, because we use the tool every day. You don’t get this from UX research reports. A bunch of user quotes and cartoon avatars is one thing; going through the same repeated motions as our customer, day in day out, gives us true intimacy with a users’ context.
We identify frictions faster. If some part of the experience is broken, we don’t need to wait for someone to report it. We will find it because we’re feeling the problem as we use the product.
We want the same things our users want. Instead of asking our customers what they want and trying to make sense of their answers and prioritize them, we become our own customers. We will better understand all of the product’s problems and have a clear intuition about what needs to happen first. We don’t need to interpret anything. We also know which bugs are nitpicky and which are mission critical.
Yes, there are downsides to dogfooding.
It’s humbling. It’s painful to realize that your product’s limitations are “your fault.”
It’s different from what we’re doing now. It’s much easier to build incremental stuff that middle managers love and users are indifferent to. Why rock the boat? (Is that a sniper dot on my forehead?)
It’s painful. Building tools is about specialization; no tool can do it all. We would be pushing our product to do things it’s not “meant to do” and this can be annoying.
(That said, our customers do this all the time; using and stretching what our product is the way to unlock new features and SKUs. I can’t believe I just said that.)
Some folks don’t see the value of dogfooding. This is what they say to me.
It’s not useful because it’s not exactly the same at what our users are doing.
We are not our target customers, it’s true. But to be frank, there is no monolith called “target customer.” They all have different needs and goals. But the one thing they have in common? They all (seem to) love using our product, or at least they love it enough to use it every day. The one thing they have in common is using our product. Should I say that again? The ONE THING they have in common is USING OUR PRODUCT. (Shall we join the club?)
Second, I fail to see how doing something kinda different from our customer is preferred to doing nothing at all. This is continuous quality assurance, plus user research, plus empathy building, plus product training, for free. What’s the catch?
It would take too long to set up.
WTF. What else you got going on that’s so important?
We don’t need to actually dogfood, but this does provide an opportunity to think about the underlying….
I know admitting you have a problem is the first step, but you still have to do the other steps. You can’t just think about working out, you have to lift the actual weights.
This objection irks me because it completely intellectualizes the problem of design, when good UX design is also about feeling.
UX is applied cognitive psychology, not graphic design with CSS. And a user experience is not just veneer. It’s moving the mouse around and understanding tap targets, and entering data, and waiting for things to happen. Haptic stuff. To say dogfooding is useful, but not actually do it is some bullshit.
It distances us from the beginner’s mindset.
This a true and valid downside to eating your own dogfood. You become a power user (like some of your users), and power users are often blind to simple bugs and design flaws. When you use something a lot you have the potential to internalize non-optimized, biased, or even destructive behaviors—and hell you might even grow to love these antipatterns because Repetition breeds affection. And because our software is an intermediary between humans, we should take this shit seriously.
But this is a blind spot to dogfooding, not a fatal blow. Make your teams diverse, test often, challenge your own assumptions, Respect the user, do one thing at a time, Start with the story, do all the things that good designers are meant to do and I think you’ll be OK.
This is a massive undertaking. In the old days someone would have sent out a memo saying “no more typewriters” and this would happen overnight because you’d fire everyone who didn’t comply. Instead, we have to ease into this like a hot tub.
So let’s think about this another way. “Dogfooding” as a new product we want to sell. Adoption of any new idea, behavior, or product (i.e., “innovation”) does not happen all at once. Some people are more apt to adopt the innovation than others (Diffusion of Innovation Theory, Rogers 1962).
We have over [Redacted] employees at Zendesk as of April 10, 2023. Today I don’t need our software to do my job. It doesn’t help me at all. The dream is that all of us could rely on our software for (at least) one of our top five daily workflows. If we can do that, that means any of our customers could.
To start, let’s focus on 2.5% percent of our employees. The innovators. Can we get 100 designers to start using our product the way our customers use our product?
Thanks for reading this far, you’re a champ.