How to extract unbiased insights from customer calls

Part 3 of the PMF sprint playbook

Congratulations! 🎉

You’ve managed to get on a call with a potential ideal customer. The hard part is over; now you get to have an interesting conversation with them, trying to uncover the hard truth about their context and motivations.

Nothing feels worse than realising you’ve spent days or weeks building something no one will use or value. Today, I’ll show you how I try to uncover the truth behind every customer conversation.

In case you missed my previous posts, this is part 3 of my PMF sprint playbook. Don’t miss out on previous topics below:

Part 1: How to run effective PMF sprints

Part 2: How to get people to talk to you about your ideas

How to f*** it up

It’s surprisingly easy to do. We’ve all done it. That’s how we end up wasting time working on the wrong thing, or worse, “validating” tarpit startup ideas.

Here are some bad questions and why:

• Solution-first questions: “Would you use my idea?” → Courtesy yeses.

• Hypotheticals: “How much would you pay?” → Fantasy pricing.

• Leading phrasing: “Do you have a problem with…?” → Interviewer bias.

The most common pitfall is to fall into pitch mode and start talking about your idea or solution. The goal of these calls is to learn, not sell. Most of the time, however, I’ve found that the interviewee will want more context and start asking you probing questions. Counterintuitively, I usually found that providing some context up-front can prevent them from wondering what this is about and focus the conversation on them, not on you. For example:

I’ve seen [persona] having some success with [problem] using our product. I’m curious to see if this will resonate with you. Can you show me, step-by-step, how you currently do [job to be done]?

Asking good questions

First of all, what are good questions? Let’s look at the examples from earlier.

• “Would you use my idea?” → “When is the last time you tried to solve [problem]?”

• “How much would you pay?” → “How much time (or money) did you spend on this?”

• “Do you have a problem with…?” → “What was frustrating about that process?”

Notice that these are anchored in the past, which is real, tangible data that they can’t fake or go back and change. Steer clear of opinions and focus on getting them to tell you stories.

I’m not going to sit here and pretend that this is easy, and I do this perfectly. Honestly, most people won’t think that what they’re doing is wrong or can be improved. This usually means that starting with a generic opening asking about the pain or frustration won’t work. Don’t do this:

Hey, nice to meet you. […]. What’s the most frustrating part about [job to be done]?

A real example of this happened to me recently when an ICP described an incredibly manual process in Notion. She was spending probably a couple of hours a day on something that another tool could do in minutes. My immediate reaction was “wow, this sounds like a lot of admin”. She agreed, but said the perceived value they were getting out of good-looking Notion documents was worth it. Seeing an opportunity, I followed up with:

“When was the last time you tried to change or review the process?”

She then finally admitted that they could be more efficient, and this wasn’t ideal, but they haven’t done anything about it. I asked more questions related to why they decided to use Notion in the first place and who made the decision. I quickly realised she was championing the tool and process internally herself, and it didn’t seem like a burning issue, so I moved on. Looking back, I made a huge mistake. I could have drilled down even further by asking questions like:

• “Has anyone in your team complained about this?”

• “If you could do this in 5 minutes per day or not at all, what would you choose to focus on instead?”

• “What would be the impact on your output?”

3-step unbiased flow (PIT)

I’ve tried to keep my process in these calls very simple to let the conversation flow: beginning, middle and end. As I mentioned in Part 1, being too prepared and rigid can really kill the buzz and honest exchange you have with someone. I usually try to stay open, sincere and show some empathy whenever they describe a pain point in their workflow.

We’ve already discussed the opening and closing statements at length, so let’s focus on the most important bit: the middle. I’ve come up with a quick acronym to codify and remember this: Process, Impact, Timeline (PIT)

Process

“Show me how you …” — screen share if possible, to uncover the real workflow.

Impact

“Where did you spend the most time?”

“What would be the impact on your work if you could easily do this in 5 minutes or not at all?”

Try to let the emotions and frustrations come out naturally at first, and if they don’t, you can always follow up with:

“What was the most frustrating part?”

Here, the goal is to uncover and quantify pain points they care about.

Timeline

“When did you last do this?” — anchor details in a concrete past event and timeline.

“How often does this happen?” — separate chronic pain from edge cases

Bringing it all together

I’ll leave you with a quick summary cheat-sheet that you can download, re-use and study in between calls

Remember to transcribe, take notes and share takeaways with your team! If you do these right, you’ll walk away with a ton of valuable insights.

Hit subscribe so you don’t miss the next “build-or-kill” post! 👋