Solution Interview

A Solution Interview helps you learn what customers think about your product through a presentation or demo, to validate product/market fit

Jordan Duff avatar
Written by Jordan Duff
Updated over a week ago

Overview

Method category: Generative product research

How to Use This in GLIDR

A Solution Interview helps you learn what customers think about your product through a presentation or demo, to learn if your proposed solution actually solves the problem they have.

In GLIDR, Solution Interviews can be used in Research to learn what customers think about your product. First, Plan your Research and connect ideas about your product. Then, for each interview you conduct, add a piece of Evidence - Interview and note salient aspects like a feature the customer was excited about, any strong negative critiques, or the price point that the customer agreed to. Finally, when you've finished the interviews, synthesize what you've learned in the Analyze phase to figure out how to proceed.

Learn more about each of those aspects of GLIDR:

---

Solution Interview

Article excerpted from The Real Startup Book

In Brief

The solution interview builds on your research about the problem and proposes a solution, in order to see how potential customers react. Solution interviews result in qualitative feedback from users or prospects about the product, when presented with the product or a prototype. Use a “demo” to help customers understand your solution and confirm that it will solve their problem.

Helps Answer

  • What is the minimum feature set needed to launch?

  • What are "must have" features/benefits for the user?

  • Will the solution "work"?

  • Where are the solution’s strengths and weaknesses?

  • Is the copy/presentation right?

  • Why is the price right/not right relative to alternative ways of addressing the problem?

  • How do I create the groundwork for repeat sales?

  • How does the product fit into the prospects' existing technology mix (for B2B tech especially)

Tags

  • Qualitative

  • Demo

  • Visualization

  • Price

  • Features

Description

The biggest risk product entrepreneurs face is that they’ll create a product that absolutely no one wants to buy. Problem interviews help identify common problems within a particular market segment. When you have identified a clear problem, solution interviews help nail down the reasons why or whether a particular product "works" for your early adopters.

Often solution interviews are performed with some kind of a proxy for a product, created to spark a conversation with the prospect or customer. According to @ashmaurya, "You want to build enough of the solution (or a proxy, like screenshots, a prototype, etc.) that you can put in front of customers for the purpose of measuring their reaction and further defining the requirements for your minimum viable product (MVP).”

The primary goals of solution interviews are to:

  • Define the minimum features needed to solve a previously identified problem.

  • Have a found price the customer is willing to pay (to check that you can build a business around it).

For smaller $ value products, you may want to perform some kind of a smoke test instead. A solution interview is a useful way to prepare a smoke test or to understand why a smoke test didn't pass your research hypothesis.

For a larger $ value product, the solution interview may feel like a consultative sale. Nonetheless, it's primarily a research tool to help adjust or customize a product to real customer needs.

Like other types of customer interviews, solution interviews are best done in pairs. One person takes notes during the interview. The other actually asks the questions and focuses on building rapport with the user.

Time Commitment and Resources

This is similar to initial customer discovery/problem interviews.

  • Rounds of interviews to test one hypothesis can range from 5 to 100 interviews.

  • Actual interviews last anywhere from 5 minutes, for consumer products tested using "man on the street" interviews, to 2 hours, for detailed B2B requirements gathering.

  • Time costs can be significant, in terms of recruiting appropriate interviewees, particularly ones who currently have the problem you want to solve and who are in the target segment.

  • Financial costs: Depending on context, you can offer gift certificates or a symbolic gift if you feel it's appropriate (e.g. in a B2B scenario).

How To

Determine what you want to learn before conducting interviews, and formulate a research hypothesis.

  1. Greet the user/prospect.

  2. Confirm that they fit all of your criteria and that they have the problem you currently want to solve.

  3. Set the problem context by telling a story.

  4. Reflect/reconfirm the problem back to the customer.

  5. Propose/demo a specific solution.

  6. Optionally discuss pricing, particularly relative to alternative products.

  7. Ask "what you need to do to make progress?"

  8. Get permission to follow up and/or for referrals.

  9. Document your results, ideally a small A6 notepad that fits in your pocket if you are out on the street.

Interpreting Results

Use the solution interview to plan the initial feature set of your product and determine pricing strategy.

Potential Biases

  • Leading questions: “Do you usually add products to the cart or use the one-click-purchase?” miss the opportunity to actually learn how the user uses Amazon

  • Allow the user to tell you what they think the product does and what it could do.

  • Give the user something to react to, rather than making them imagine how the product makes them feel.

  • Be certain you are interviewing the right user, i.e. someone who is currently seeking out a product like the one you are making.

Field Tips

  • "Forget all about the art of Pitching, you want the art of Dialogue." @Justin_Wilcox

  • "Don’t ask users to imagine a feature." @DaisyHappy2014

  • "Allow the user to tell you what she thinks the product does and what it could do for her" @LauraKlein

  • Got a tip? Add a tweetable quote by emailing us: realbook@kromatic.com

Case Studies

References

Did this answer your question?