Talk to your customers

As we’ve discussed, good product development depends on good communication. And dev teams exist to solve problems. So the line of communication from customer to developer matters a lot. Too often, this becomes a game of Telephone where details, clear problem statements, and empathy fall by the wayside.

The least error-prone line of communication is the shortest one. And so you, dear developer, must talk to your customers. Listen to them. Shadow them. Watch them work. Build a relationship. Know some of them by name. This will save you from all sorts of communication woes. And it will ensure you’re building a product that actually solves problems.

It's important, but it's not easy. At the bottom of this post, there are practical tips to do it well.

When I first started my last job, we were playing a terrible game of Telephone. Customers asked for something vague. Customer Success Managers reported that to their manager. Their manager sent a confusing Slack message (without details or a problem statement). And the PM / engineers on our team had a few options:

1. Take this vague, mangled feature request at face value and start building
2. Ask for clarifications, prompting more rounds of telephone
3. Go back to square one, and talk to the customer for ourselves

This led us to over-engineer solutions to small problems, or solve problems we didn’t need to solve. It led to wasted time, and frustration on all sides. The communication breakdown eventually led to the loss of empathy. We didn’t know our customers by name, and saw them as sources of endless, vague, confusing feature requests.

As a Product Manager, I already talked to customers a lot. But I started doing it even more. It became my greatest strength as a PM. I did hundreds of hours of interviews. For every customer interview, I added developers to the calendar event as “optional.” They often couldn’t make it, and that was fine. But they did make time a couple times per month.

The devs heard things I didn’t hear. They noticed users hitting UX friction I never noticed. They identified small problems that were easy to fix. They asked different kinds of questions than I asked. When we built features, they had clear understanding of the problems we were solving.

We built trust with customers who could see how seriously we took their feedback. Our devs knew customers by name, and would reference them in scoping conversations. This kind of empathy can turn a dev team into an efficient problem-solving machine.

This is easier said than done. Here are practical tips for how to do it.

• Ask open-ended questions (“Could you tell me about what you love most about this feature? And what you hate about it?”). Get them talking.
• Focus on pain points. (“If you had a magic wand, what’s one thing you’d change about our product?”). Walk away from every interview with a handful of well articulated problem statements.
• Listen a lot more than you talk. And take notes.
• Allow them to talk about whatever they want. If they get hung up on an issue, that’s your indicator that that’s the biggest pain point they feel today. Let them cook.

• Ask yes/no questions, or any question they can answer in a few words.
• Accept feature requests at face value. Customers are terrible at solving your product problems. When they suggest a feature, push back and ask, “What problem would that solve for you?”
• Ramble on about features and roadmaps. We get zero value out of you talking a customer’s ear off.
• Ask leading questions (“would you like this new feature that solves your problems?”). Don’t drive the conversation toward the features you care about the most. You’ll end up “leading the witness” and missing the important things they want to tell you about.

You might not have the extroverted personality to run a customer interview by yourself. That's fine. Go with a buddy. Tag along with a PM or any customer-facing team member (Customer Success, Sales, Customer Support, etc.). Those people already know customers, and are good at talking to them.

There are other benefits of tag-teaming too:

• One of you can take notes while the other asks questions.
• You build rapport with a team member you don't not spend much time with.
• You will pick up on different things. Confer with each other and cross reference notes afterwards.
• This builds a ton of good will with the customer too. “Tina is here. She’s not part of the sales team, she just wants to hear from you and learn what makes you tick.”

If you’re going with a customer-facing buddy, you can defer to them. But explain to the customer that this is not a sales call. Make it clear that we want to hear from them. We value their insights, and this is how we make the product better. As always, send concise, direct emails. And thank them for their time.

Talk to a broad range of people: power users, people in the sales funnel who aren’t customers yet, paying customers who are failing to use the product, etc.

Over time, build a “panel” of customers. Go back to the same people over time. Get to a point where you have 20 email addresses of customers who know you by name, and reach out to them regularly. Once they know you, you can also send them quick emails for feedback on smaller things. This becomes insanely efficient and useful over time. By the end of my time at Binti, I would make clickable prototypes of new features, and send them out to my panel for rapid feedback. My inbox would have dozens of useful responses within the day. Some customers love to doing this. It's about building a great product for them. And talking to them is the best way to fold them into that process.