One of our core values at DataFox is empathy. We hire people who are driven to help others, and this defines our culture and our product.
But here’s the thing: empathy isn’t just a nice word on a poster. It’s a feeling. You don’t empathize by understanding a problem, you empathize by seeing it and experiencing the pain for yourself. It’s feeling someone else’s pain that inspires action and solutions.
So how do you make the people who build the product feel the customer pain when they aren’t the target customer? We’ve already discussed one solution: empathy hackathons. Today I want to add another: shadowing customer calls.
Yes, it’s an obvious idea, and we certainly don’t claim credit for it. But it’s effective, and I encourage others to make it part of your culture.
Wait, isn’t this the product manager’s job?
The traditional notion is that PMs are responsible for interviewing customers, unearthing their needs, and translating those needs into technical requirements to hand off to engineers. This is all great, but it’s not complete.
The problem here is that something is always lost in translation. As engineers make technical trade-offs it’s easy to compromise what the customer actually needs. The result is technically correct (according to the spec), but actually misses the mark.
Asking engineers to build products based on written specs is like hosting a movie night where you all silently read copies of the script. Written specs, like scripts, are necessary, but no subsitute for the real thing. To build great products, engineers need to feel the customers’ pain, just like you need to see the actors to connect to the movie.
Great PMs bring a lot more than just requirements to an engineering team. They bring the customer’s story. Better still, they bring the customer and let them tell their story.
That’s why our engineers shadow customer and sales calls every month. We even track it as an OKR and report it to the rest of the company. They take notes and then share a brief summary at the weekly engineering meeting about what they learned.
It’s simple, but it’s powerful.
Just don’t expect every call to be an eye-opening experience. Yes, at times there is a gem of information that helps the engineer build a new feature. But that’s the exception. 90% of what we hear is not new information, which is how this should work. If engineers are regularly exposed to customer feedback they should already know about most requests.
But that’s not the point. The point is the power of seeing something with one’s own eyes. I’ve known that a workflow was poorly designed, but it’s not until I see someone struggle through using it that I feel galvanized to fix it. Similarly, hearing a customer ask for a feature makes it more personal than a Jira ticket. These small insights add up quickly.
A final thought
The biggest challenge to getting engineers to shadow calls is to have the right engineers in the first place. It’s a big investment of time, so they have to be motivated by empathy. That’s why empathy is one of the core values we test for in our interview process (and not just for engineers).
It’s also important to convince the customer success and sales teams that they should post their upcoming calls for engineers to shadow. We always explain that this is a great way to advocate for features and concerns. But we also give away Amazon gift cards to the rep who had the most calls shadowed. Do whatever it takes to get them bought in.
In the six months since we started the program, our engineers have shadowed over 80 calls. They’ve fixed well over 100 smaller issues that came up, and helped significantly streamline our sales process. They have even deeper empathy for our customers, and the results show in the product and recent customer feedback. I encourage you to try making this a core part of your engineering culture as well.