Customer Zero
The Difference Between Cat Herders and Dog Fooders
As companies get larger and more complex, there’s a tendency to manage to proxies. A common example is process as proxy. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing.
Ever have one of those days when you’re doing the thing but you’ve lost track of why the thing is THE THING? We all have those moments, and in such instances I find it useful to reset my state of mind to something I’ll call “customer zero”.
My team in my Kindle days worked on a variety of cross-org problems, one of which was running beta programs for new product launches. We had a couple of teammates that ran that effort like a well-oiled machine - device after device, release after release, patch after patch went through a rigorous cycle to ensure it was customer ready. And (this didn't dawn on anyone at the time) it really was just a couple of folks managing beta testing simultaneously for multiple products. Just goes to show that when someone truly owns something they scale up to do more and make it look easy to outsiders.
One day (let's call it the start of the perfect storm) everyone who knows anything about running beta efforts goes on vacation. There's a backup plan in place where we have anther person on the team manage the day-to-day work, which basically entails:
reviewing the incoming queue of reported bugs
verifying issues by going through the same actions as the user
updating tickets with details (screenshots, build details, stack traces)
cleaning up multiple reports of the same problem
tracking progress of fixes for high severity issues
communicating with the participant pool on updates / patches
That was our high-level understanding of what the beta folks did day in and day out. That was, in fact, my understanding of it (shame on my former self) - so when I had someone cover for the out-of-office folks, I diligently ensured that their explicit responsibilities were what we focused on. But I completely neglected understanding what they implicitly owned.
So, this PM on my team starts managing the beta feedback. And he goes absolutely nuts. A couple of days into it he comes by my desk with an epic rant…
He can't keep up with the feedback. He can't follow the user reports to reliably recreate bugs in our environment. The beta pool is using n different builds and he never knows if bugs aren't fixed or people are just on stale builds. It's hard to take a screenshot with the device. Every report of "critical bugs" he sends out is out of date the minute it leaves his inbox. He's spending all day resolving duplicate tickets in JIRA. It's too easy for people to auto-file bugs from the device but they won't respond to his emails asking for more details. He can't do it anymore - he needs help.
I immediately get him help to deal with the volume of work and make a mental note to follow up with the usual beta leads to understand how they manage things. Clearly the veterans had been approaching things in a way that was less stressful and more sustainable.
Everyone gets back from vacation and we do a little pow-wow on how things went. For the folks who covered the program, the general vibe was this had turned out to be more work than expected and the knowledge transfer wasn't handled well. They walked into the discussion with "you didn't tell me there was this much cat herding!"
Our more seasoned beta leads listened to the feedback, chuckled, and then responded with:
"Cat herding? We don't herd cats. We spend all our time dog fooding."
Silence.
"What?"
"All we do is play with the device and dogfood builds. All day, every day. We pretend we're users. Everything else is just noise."
"What?!!"
"No one knows this product better than us. We are customer zero."
"How do you deal with the zillion JIRA tickets?"
"We rarely see a ticket that we don't already know about. We only go into JIRA occasionally to bulk select and resolve as known. Were you spending all day trying to keep up with the never-ending tickets?!"
"But how do you generate the top issues list?"
“That's everything getting in the way of shipping - we just use JIRA tickets to validate that we're not the only ones thinking it's a ship-blocker."
Silence.
From that day forward, we revised the beta lead job description:
dogfood the product all day long
That was the gist of it.
I'm over-simplifying for the purposes of storytelling, but the lesson we learned was owning something (in this case product quality) was a better approach than going through the mechanics of generating artifacts (in this case critical bug reports).
So if you’re ever having one those weeks where you feel like you’re going through the motions…pause, take a breath, and put your “customer zero” hat on.
I’d love to hear from readers (via comments section below) on situations where they got caught up in serving the process vs. serving the customer…
further reading / references
the quote at the beginning is from Amazon’s 2016 letter to shareholders
childish drawing / interpretation
