How we got our first customers without writing a line of code

When we started Mistro, we went through rapid iterations of our product concept. Though we could have begun building a product we thought was relevant from Day 1 (and were quite eager to do so), we didn’t. Instead we conducted over 100 user interviews with HR specialists, remote employees, and founders. Then, once we had an understanding for a product that was resonating, we signed a few pilot customers (who also agreed to pay us!!). Finally, it was time to build.

It was important to us that whatever we ended up building was informed by real people who may end up paying for our product. The 100+ customer discovery calls we conducted played a valuable role in enabling us to rapidly iterate on product ideas, simply by asking the right questions.

Eventually these customer discovery calls turned into sales calls, which is how we knew we were hitting a real pain point.

Here’s how we did it:

Step 1: Set up your hypotheses

Figuring out the information you need to validate early on before building your product can save you tons of time and headaches later on. You are able to mitigate the risk of building a product that no one wants to use or buy.

Writing down your hypotheses is a critical step in structuring the information you want to get out of each customer interview. For example, in the early days of Mistro we were interested in how remote companies got physical items to their employees when they were scattered across different continents. A few sample hypotheses included:

  • Remote companies regularly send physical items to employees (welcome packages, birthday gifts, etc).
  • Remote companies believe physical touchpoints are important to build culture.

These hypotheses serve as the backbone to help formulate the questions you want to get answered in the customer discover call.

Step 2: Create your customer interview guide

Before the call, you’ll want to prepare so that you can maximize your time with the participant. The purpose of the customer discovery call is to learn about your end-user and a list of questions can help you keep track of the information you need to collect. This list acts as an outline of subjects you want to touch on during the call.

First, you’ll want to collect any contextual information that may influence their answers. For example, asking about company size, and specifically size of their remote workforce, gave us important contextual information to group our insights.

Next, you’ll want to focus on deriving objective questions from the list of hypotheses you have. Remember, you want to learn about if your hypotheses are true, or not. If they aren’t true then you can continue to iterate early before you’ve invested a lot of time or energy into the product. For example, we had questions like “What benefits/perks does your company offer for remote employees?” and “How often does your company send physical items to remote employees?”

Last, I usually like to end with the magic wand question. For our purposes, we kept it pretty vague: “If you had a magic wand, what would you change about remote work?” This enables the interviewee to surface new information they may not have been able to talk about yet — or emphasize a pain point they discussed. Sometimes you’ll get tangential answers that you can’t fix, i.e. different time zones are hard to coordinate. However, other times you’ll find real gems.

Step 3: Conduct your customer discovery call

The call itself should be thought of as a conversation. The first few minutes set a precedent for how comfortable the interviewee feels about sharing information. Start out by making general small talk, giving them context on the purpose of the customer interview, and thanking them for their time.

After that, go ahead and dive into the interview guide you made. Start with the contextual questions you have and then dig into the meatier set of questions. Again, it’s important for the call to flow like a conversation so based on the context don’t be scared to jump around the questions you prepared or diverge from the guide you created completely. When the participant says something interesting, dig deeper and find out more.

Another important point: don’t ask leading questions. For example, instead of asking “do you wish your company offered more benefits?” (which often times, the answer is yes, who would say no to more free stuff), ask “how satisfactory is your current benefits package?”. Your hypotheses may be invalidated and that’s okay! The point of conducting these customer discovery calls is so you can find holes in your idea early on, before investing tons of time and money into product development.

Step 4: Iterate!

The last step is to continue to use the information you gathered to iterate on your hypotheses and product offering. As hypotheses become validated and invalidated, new questions unlock. While you go through this process, you’ll be able to refine what you know and don’t know until you have a product idea that is based on what customers actually need.

Eventually, at the end of the customer discovery calls you can start describing the product you are thinking of building. We still remember the first time someone said “yes, I need this right now” after we described our potential offering and we scrambled to schedule a sales call as a next step. If multiple people start saying that they would be interested in paying for it, then that means you may be on to something you are ready to start building.

That isn’t to say your product won’t continue to evolve. Like any startup, you’ll still need to prove out if people are willing to pay for your product. However, now when you go out to start selling, you’ll be much closer to the mark.

— Sarah Ahmad, Co-Founder of Mistro

If you have specific questions or additional tips about conducting customer discovery calls, I’d be happy to connect at sarah[at]

Mistro makes it easy for remote companies to provide benefits to their distributed team. Learn more about how we’re thinking about benefits and the future of work.

Leave a Reply

Your email address will not be published. Required fields are marked *