Sarah Louis-Jean, an aspiring dancer from Vancouver
It’s an invigorating feeling to be the driving force behind bringing something new to the world. Alas, innovation happens under conditions of extreme uncertainty. Especially because your goal goes beyond just creating something new. You are trying to discover, build and tune the fine mechanics of a business model. A machine that will repeatably acquire increasing number of customers, and delight them enough to part with their hard earn money.
At the center of this discovery process is a very human customer. And a very human activity: talking to them. Here’s couple of thoughts on how to do that (and how not to do it).
1. Don’t sell, convince or (god forbid!), argue. Listen. This is as obvious as it is easily forgotten. In our eagerness to convince, we may ruin the opportunity to learn. We need the customer to feel encouraged to give us their honest opinion and feedback, rather than defend themselves or argue. Eagerly listen and show true empathy and understanding. Show genuine interest. If you are really passionate about the product, you’ll need to be passionate about the market, and in the center of that market is that person sitting in front of you. They are the most important stakeholder, and you want to know them as much as you can.
It’s okay to ask follow up questions to drill down to the root-causes. It’s also okay to take charge of the conversation.
2. Don’t ask them what they want. Not because we don’t care about what our customers want. It is because you cannot simply outsource your innovation to customers. The responsibilities are divided like this: you, the visionary, own the solution, and the customer owns the problem. It takes lots of imagination to think up a product. It takes a big leap of faith to believe the product will effectively solve the tough customer problem. Your customer is already doing their best to deal with it.
I’ve done a couple of interviews during the early, vague stages of my idea. I distinctly remember a potential customer telling me something along the lines of “yes, this is certainly a challenge, but I just don’t see how a software tool could solve this”. When I later started showing, in a clear and visual way, how my solution would look like, the reactions were very different.
But enough about what not to ask. Let’s focus on stuff we can talk about. You first need to figure out why you are doing this round of interviews. If that’s clear, here’s some ideas on how to go on.
3. To validate the problem you are solving, you can start by saying “what I want to do now is to describe the problems we are solving and see if they resonate with you. Does that sound good?”. Then, for each of the problems, you can:
- Describe the problem: in my experience as a/working with <customer role>, I’ve observed we often struggle with <short problem description>
- Ask: does that resonate with you?
- Listen, write down, and observe their body language (to assess the level of difficulty). Pay attention to the specific words they use to describe the problem
- Ask: why is that difficult? Here you want to drill down to root causes. Often, people will describe things about their work or everyday life without giving you the context. You want to drill down and make sure you really understand the problem from their point of view
- Rate: I like to ask my customers to rate the problems on scale from 1 to 5, 1 being “irrelevant”, 5 being a “must have” . This allows you to rank problems, and it often surprises me
Take some time to prepare by describing the top 2 or 3 problems in clear and simple words. Try to do it from your customer’s perspective. A small note on wording: there are cases (and customers) where the word “problem” is not always appropriate (or appreciated). A small hack is using the word “challenge”.
4. To validate your solution, you’ll need visuals in addition to words. Live product or screen shots / mocks. Make sure you also take the time to prepare a simple and clear story around it. There is a great chance your customer will simply not understand you. And they might not admit it as no one likes to seem stupid. This can make for a very discouraging and frustrating conversation.
I like to create a couple of supporting slides containing visuals glued in a logical story line. And then test it a couple of times on innocent bystanders. A rule of thumb is to contain your story to max 3 top features / screens. Ideally, each of the features solves one of the three identified top problems.
Depending on your product, you might need more than just screens. To help you get funding for your innovation, Grant Snap turns the complex research grant proposal into series of clear and actionable steps. Therefore, an important part of our product is the “recipe”/workflow – the actual steps. When I showed an example screenshot to a professor with 30+ years of experience, he got stuck on the example steps I was showing. If a key about your product is content, data or results, the examples have to be compelling. Don’t use “Lorem Ipsum” on your slides.
What you can ask after telling your story is:
- If our product were free and available now, would you sign up and use it?
- Are you missing something important?
- Which of the screens resonated with you the most?
- Which could you live without?
This technique can provide lots of information and save you wasted months programming features no one is interested in. However, there is a world of difference between having screenshots presented to you and using the actual product. You need to get your first version in front of your users and start iterating quickly. There is no excuse not to start with product development as soon as possible.
5. To validate pricing, your only true option is to really sell. Consider this option for a moment. Go out and sell the specs, the promise. Some people do this. Here are also a couple of useful alternatives.
A straightforward test is simply asking the customer if they would be ready to pay €X for the product. After you see a strong resonance with problem and the solution. To borrow Steve Blank’s idea, you might ask: “if this product were free, would you install it tomorrow?”. And then follow up with “Unfortunately, it’s not free, it costs <an outrageously high price>“. Steve testifies that some customer’s response was to say “come on, you got to be serious, I would never pay more than <their actual available budget> for it”. Nice! If you can make this work of course.
Here’s some other ideas. People with B2C products or lower pricing, might put up a fancy landing page that contains three pricing schemes, and count and compare clicks. People building B2B products can draft a non-legally binding letter of intent based on specs and foreseen pricing, and try and get their customer to sign it. The success here is not necessarily about the customers actually signing, but what you learn from their reaction.
You might also simply ask if there is budget available, and who has to approve purchases.
6. To validate channels, you can try to fish out how and where do the customers look for solutions today. Ok, so the problem we talked about clearly resonates with you. Did you already search for solutions? Where? How? Via a search engine you say? Which keywords did/would you use? In addition, for B2B, you might inquire to see if there are specific roles in the organization whose responsibility will be to find, purchase and evaluate new systems / technologies.
At the end of the interview, which should not be too long (I try to do all my interviews within 30 minutes), you want to make sure it’s okay to follow up. You can ask if they would be interested to see a demo once the product is ready. In addition, this is an opportunity to ask for referrals, other people from the industry to talk to.
How do you interview your customers? Do you think these techniques would not work in your case? Let me know.
