SaaS Customer development interview 101

I haven’t done customer interviews before. I avoided doing this in my earlier startups for the reason that I’m worried of talking to people one-one. What if they don’t get what I’m speaking? What if they squash the product vision and ridicule my product/feature idea just because this SaaS idea is not fine tuned to their custom requirement? Or the embarrassment of not being understood clearly of your product vision is hurting. But deep down, I know that I should be doing customer interviews to avoid shipping a feature that nobody wants to use.

I brushed up some people skills and learnt that customer interview process is more about getting people to talk their pain points than me blabbering out solutions and what we are going to build. Being a product manager for an enterprise B2B SaaS product, one of the core duties is to get out of the building and talk with the signed up customers on their usage behaviours. I did that.

1. Keep it conversational
I didn’t record the interview. Audio recording will make customers more conscious of what they speak. My type speed is 65WPM (decent) and so I took the meeting notes on my mac while I listened and saw their screens.

2. Ask the right questions 
Avoid false positives. Lesson: Avoid false positives. Asking “Do you like to see all your ad stats in …?”, “Do you like to search campaigns with…?” always resulted in Yes. As much as I knew to avoid these yes/no questions, I did ask in couple of instances.

3. Write meeting agenda 
Send it across the team. Prepare points that you are going to discuss with the customer. Crowd source any other pointers from the team. Send the final agenda to the customer few hours before the meeting.

4. Listen 
Separate feedback, issues and feature requests. Make sure that the customer isn’t deviated while talking on a certain module of your product. Listen to what the person has to say completely before coming up with solutions or work arounds.

5. Don’t give Estimates
Do not give any deadlines about shipping a feature that can’t be adhered to. It’s tempting to say we’ll have it in a week. But no unless you go back, think, write detailed description and do mockups you are not going to know how long a certain thing is going to take. In fact, you shouldn’t even commit to building anything. Let their ideas flow, take note and brainstorm later. Prioritise them only if they align with what you wanted to build in the first place.

Once you are back, send the meeting notes to your team. As you take decisions on those items, keep the customer informed.

Do you have something to add up? Let me know.