Ask HN: What does your customer interview process looks like?

Are you talking about a Customer Development interview? If so, it depends on what phase of the process we're in. I'll answer relative to the very first discovery level interviews, since those are the ones we've done the most of:

How many people do you talk to on each batch before you sit down to analyze the feedback?

We analyze feedback after each interview. After a few (say, 3-5) we would sit down and synthesize / aggregate and look for patterns, etc.

How do you go organize and go over the feedback you got?

Right now it's a pretty manual process. Notes are stored in Google Docs documents (one per interview) and other docs are used to store the synthesized observations and what-not. Keeping track of the process itself, scheduling interviews, etc., is pretty adhoc... a combination of Google Calendar, spreadsheets, various text files, etc. We've recently deployed SugarCRM, however, for at least managing contacts and what-not. Ideally we'd like to use a Customer Development specific tool which "knows" the CD process and workflow, but we haven't yet bothered to find or write one.

How many questions (in avg.) do you do on each interview?

We have a canned list of about 40-50 questions we can use, but not every question is used on every interview. Answers to previous questions affect which subsequent questions get asked. On average, we probably wind up asking about 25 meaningful questions.

When we are coaching companies through the problem interview stages we set some basic ground-rules.

Interview at least 30 target customers. Anyone who doesn't fit into your pre-determined persona doesn't count.

Set the success/failure criteria before the interviews. For instance, we are going to talk to 30 potential customers and we are going to focus our questions about a pain point in this particular area. Of those 30, 21 will agree they have felt pain when dealing with this area.

Typical number of questions is 10, mostly to qualify them as fitting in the demographic. Take notes mentally, but not during the interview (taking notes during the interview infers a test and they will try harder to get the "right" answer). Immediately after the interview, document the interview. Make sure to allow the interviewee to elaborate on any question, as they may reveal other areas with pain. If they admit pain in the area you are targeting, ask them what they are currently doing (your biggest competitor may be that they aren't doing anything). Then subtly try to talk them out of the problem being a pain. If you can't talk them out of it, it is indeed a pain point they want solved.

Once you have 30 look at your interview summaries, determine if you have validated or invalidated the assumption. If invalidated, really look close at the responses you did get, since they will reveal other problems to explore.

I usually will ask the person I'm interviewing to describe their job or the activity which I am posing a solution to. In the case of my startup, I'll ask them to describe their experience planning and running a conference as if I knew nothing. Their pain points will naturally emerge as they describe their processes, and their real issues usually become obvious by the way they describe their job (even if they don't know their issues consciously themselves!).

I usually go for long interviews (30 minutes to an hour) and look for commonalities between them after every batch of 5 or so.

If more than 2/3 of the people express a pain point, I know there's a real problem there. In my case, I'm trying to craft an MVP with 3 or so main features. Every person I've interviewed so far has expressed the same base 3 pain points (in addition to other needs which varied from person to person) so I know what I'm going to focus on solving with my MVP.

I usually use around 5 questions an interview, but sometimes I've asked as many as 10 or 15 depending on how talkative the person I'm interviewing is.