|||

We must eat our own dogfood

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 don’t listen to real estate agents

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:

  • Choose One Thing to do every single day.
  • That One Thing should answer the One Question.
  • That One Question is this: What is the one thing I can do right now, such that completing it will make everything else easier or unnecessary?

What is the One Thing?

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.

We must eat our own dogfood

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.

Instead we spend good money

Not dogfooding costs us money:

  • We use Jira instead of support tickets
  • We use Confluence instead of articles
  • We use Slack instead of side conversations

If we don’t use our own product, why would our customer?

We might learn something

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.

What we don’t know

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:

  • Guess. We build things we feel like building without knowing whether it’s useful.
  • React. We build things based on executive fiat or market trends without thinking about the big picture.
  • Rush. We build things halfway and rush them to EAP without plans to complete the experience.

This is painful for employees and customers. I don’t like pain, nor do I like doling out pain. Do you?

Man, dogfooding sounds hard

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.

No, let’s do research instead

Want to know what a marathon feels like? Here’s how:

  • You can imagine it
  • You can read a bunch of articles about it
  • You can ask people who have run a marathon about it
  • You can run 5K and then extrapolate from that experience
  • You can actually run a damn marathon

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.

Empathy is earned, not learned

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 can’t just rely on research

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:

The articulation 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.

The worth-mentioning bias

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!

The faster-horses bias

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.”

3 Benefits of dogfooding

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.

And 3 downsides to dogfooding

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.)

There are objections to dogfooding, which I will address right now

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.

A modest proposal

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.

Apple eating their own dogfood

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.

Up next The definitive post on whether chatGPT will take your job Nobody knows. No one on LinkedIn or Twitter knows. No one at the New York Times knows. None of your favorite politicians know. Even scientists The Three Sees of Content Design When designing an experience, principles can help you feel confident choosing among different approaches. But it’s tricky. There is no “absolute
Latest posts Metal is hot How to write content patterns Seven things I know Your video meeting is too damn big The Three Sees of Content Design We must eat our own dogfood The definitive post on whether chatGPT will take your job The new clothes fallacy A Smallish Book about content design How to make Confluence less horrible I am a writer designer Work is like a hill Badge of dishonor Ceci n'est pas un poubelle This sign is a crime Beware the lure of consistency Do not water Never, ever use the term microcopy You need three things to design content Permanently fixed Assembly instructions for a side table Extraneous labels, ignored conventions The double diamond model Don't have an emergency here Product tours that don't suck Quickly edit text on the web How content designers can get the most out of user interviews Let's be reasonable How to derisk trial experiences Turn around, bright eyes We could be zeroes