I was doing a customer development interview a few months ago. The interview started off well, but it quickly became slightly uncomfortable, for me at least. Since I work in the Developer Division at Microsoft, the person I was talking to was a developer. I had asked them to tell me about the last time they wrote some code. As they told me their story, they mentioned some technology that I wasn’t familiar with. I didn’t understand what they were doing with the technology or how they were using it. How could I make progress in this interview without sounding ignorant or without asking dumb questions?

As it happens, this scenario isn’t all that unusual. In fact, it’s very common that I don’t know much, if anything, about the topic that my interviewee is talking about. I almost set things up that way intentionally.

In any customer development interview I do, I make the interviewee be the focus of the interview. I tell them that I want to learn about them and how they work. They are the experts in how they work; I am the apprentice, learning from their expertise.

This makes it clear that the interviewee and I might not necessarily share a lot of common ground. And it makes it more acceptable for me to ask more detailed questions about how they work and why they work that way.

Whenever I find myself in a situation where I don’t know anything about the topic that the interviewee is talking about, I can easily ask them questions about that topic from their own perspective. Why is that topic important to them? When does that topic become relevant? How did they learn about that topic? What problems does that topic solve for them?

These are questions that don’t rely on any expertise with the topic but will still yield insights about the relationship between the interviewee and the topic. And in so doing, will probably also shed some light on the topic for my own benefit.

Getting Concrete

For this to work, it’s important that the interviewee talk about the topic in specific detail. You need to make sure that the conversation is rooted in the details of themselves in the context of a specific scenario. Without those details, focus shifts from the interviewee to the topic.

It can be hard though for interviewees to talk about themselves so specifically. It’s easier to talk about what normally happens or what should happen. Talking about what actually happened during a specific event from the past can be more difficult as there are details that need to be remembered.

One way to make it easier on interviewees is to ask them to tell a story about the particular scenario. I ask them to tell me what they were trying to do, why they were doing that, who they worked with, what happened etc. I want all of the drama and the details.

People like telling stories and they know what is expected in a story. When it is couched in that way, some of those hard to recall details start to flow more easily.

But sometimes interviewees will gloss over the details as they tell their story. They might assume you are either not interested in them or that you can fill in the details yourself. Every time that happens, I interrupt and ask them to fill in those details for me. Most often I will do this by asking them “Why did you do that?”, “How did you do that?”, “Who did you work with on this?”, “How did you know you had to do that?”.

Over time interviewees get used to the fact that I want a lot of details from them. So, they start providing the details themselves because they are fed up being interrupted by me. That means that when they start to describe how they used some tool, service, or other technology they will often naturally describe why they used it and what they were hoping to achieve with it.

But if they don’t provide those details, it’s now been established that it is ok for me to ask. Again, I’ll ask why, how, what etc. Basically, I want them to describe that tech in the context of the story that they are telling me.

That does two things.

1. It keeps the interviewee on track, focused on the story that they are describing. It avoids side-tracking them as they describe the technology that I am unfamiliar with
2. More importantly, it helps improve my understanding of the tech since I can see how it fits in with the story they are telling me.

In these cases, you have to be comfortable sharing what you don’t know. That’s why I set the interview up such that the interviewee is the expert, and I am here to learn from them.

Public Exposure

I think where this gets more difficult to do is when there are other colleagues on the call. They might be listening in, taking notes. Or they might be involved in the conversation too. In these situations, we fear looking inexperienced or unknowledgeable in front of them. We don’t want to be the ones that say we don’t know what that means. So, we neglect to ask for more details since we assume that all of our colleagues will know what the interviewee is talking about.

But phrasing the request for more details in terms of the specific story or scenario that the interviewee is describing means that you aren’t asking for a tutorial on the unfamiliar topic. Instead, you are putting the focus on the interviewee, their motivations, and their desired outcome. The only person on the call who can really know that is the interviewee themselves. Not you or your colleagues since otherwise there would be no point in doing the interview.

Embracing the unknown and focusing on learning about the interviewee means that you don’t have to be an expert on every topic before you do any customer development interviews.