Kromatic logo

The Real Startup Book

Evidence-based guides and research methods from Kromatic

5.11 Solution Interview

Two figures seated facing each other discussing a product sketch on a small easel

At a Glance

QualitativeIn-personRemoteAttitudinal
~3 days–2 weeks
$0–$300

Other names Product Interview · Solution Validation Interview

In Brief

You walk a prospect through a proposed solution — a prototype, mockup, or demo — and listen for what works, what is missing, and what they would pay. The output is qualitative feedback that defines the minimum feature set, tests whether the approach actually solves the problem, and informs pricing.

Common Use Case

You have identified a clear customer problem through earlier research and now have a prototype or mockup of your solution. You want to sit down with potential customers, walk them through it, and learn whether this solution actually addresses their needs, what features are essential, and what they would pay for it.

Helps Answer

  • What is the minimum feature set needed to launch?
  • Which features are must-haves versus nice-to-haves?
  • Does the solution actually work for the target user?
  • What are the strengths and weaknesses of this approach?
  • Is the messaging and presentation clear?
  • Is the price right compared to alternatives?
  • How does this fit into the customer’s existing tools and workflow?

Description

A solution interview puts a proposed solution in front of the people who have the problem and watches how they respond. You walk a prospect through a proxy for the product, ask open-ended questions, and listen for whether the approach actually solves their problem, which features are essential, and what they would pay. It is the step you run once you have identified a real problem — usually through Customer Discovery Interviews — and want to know whether a specific solution addresses it for your early adopters.

The interview runs against a proxy for the product: screenshots, a clickable prototype, a storyboard, or a hand-drawn mockup. The proxy gives the participant something concrete to react to instead of a verbal pitch, which keeps the conversation grounded in the solution rather than in your description of it. Two outputs matter most: the minimum set of features needed to solve the problem, and a price the prospect signals they would pay.

The fidelity of the proxy should match the question — rough enough that the conversation stays on whether the solution works, not on visual polish. For a smaller-dollar product, a Landing Page Test may be a faster way to gauge demand; a solution interview is useful for preparing that test or for understanding why it underperformed. For a larger-dollar product the interview can feel like a consultative sale, but its job is research — adjusting the solution to real needs, not closing a deal.

Run solution interviews in pairs. One person asks the questions and builds rapport; the other takes notes and watches for reactions the speaker will miss.

AI design tools generate interactive prototypes from a text description, and for software products you can stand up a working slice that simulates the core value proposition, giving the participant something tangible to react to. The interview itself stays a human conversation. Do not hand it to an AI chatbot: the signal you are after — hesitation, enthusiasm, confusion, the unprompted follow-up question — needs an interviewer who can read the room and follow an unexpected thread.

How to

Prep

  1. Define what you want to learn. Pick a single, focused learning goal — for example, which of three features participants consider essential, or whether a proposed price is in the right range. If you can’t state the goal in one sentence, you’re not ready to interview.
  2. Formulate a research hypothesis. Write down what you currently believe is true (for example, that mid-market finance teams will pay a set monthly price per seat for automated month-end close) so the interview can falsify it, not just confirm it.
  3. Recruit participants who fit the segment. Re-screen for the actual problem before booking time — feedback from someone who does not have the problem generalizes to nothing.
  4. Prepare the proxy. Use whatever fidelity is just sufficient to provoke a real reaction: a paper sketch, a clickable mockup built in a prototyping tool, or a working slice for a software product. Keep it rough enough that the conversation stays on whether the solution addresses the problem, not on visual polish.
  5. Write the interview script. Decide the story you will use to set the problem context, the prompts for walking through the solution, and the open-ended questions you will ask afterward. Plan the script to test the concept without selling it, and decide who asks and who takes notes.

Execution

  1. Greet and screen. Welcome the participant and confirm they fit your criteria and have the problem you want to solve.
  2. Set and confirm the problem. Use the problem-context story from your script, then reflect the problem back and have the participant confirm or correct it before you show anything.
  3. Walk through the solution. Present or demo the proxy and let the participant react. Do not explain features unprompted — ask what they make of it.
  4. Probe pricing. Where relevant, discuss price, particularly relative to the alternatives the participant already uses or pays for.
  5. Ask about next action. Ask what they would need to do to make progress, which surfaces real intent better than asking whether they like it.
  6. Close and follow up. Get permission to follow up and ask for referrals to others who have the problem.
  7. Capture results. Record reactions, quotes, and pricing signals immediately — a small pocket notepad works if you are interviewing on the street.

Analysis

  1. Separate must-haves from nice-to-haves. Across sessions, mark which features participants leaned in on, asked about unprompted, or named as the reason they would adopt. Those are must-haves; features that drew mild approval but did not drive the adoption decision can be deferred.
  2. Flag the dead reactions. Note features that drew confusion, indifference, or “why would I need that?” Decide whether to redesign, remove, or test them differently next round.
  3. Read the pricing signal. Pull both direct price comments and indirect cues — comparisons to alternatives, cost-saving framing, hesitation — into a range to test next, rather than a single number.
  4. Collect the quotes. Save the strongest verbatim quotes for each must-have feature and for the pricing theme; they carry more weight with your team than your summary will.
  5. Treat the data as directional. With a small sample you are looking for patterns that repeat across participants, not statistical proof. Decide which findings are strong enough to act on now and which need more interviews before you commit.
Biases & Tips
  • Leading-question bias Closed or leading questions prime participants to agree rather than reveal how they behave. “Would you use a dashboard like this?” invites a polite yes; “Walk me through how you’d use this” surfaces a real reaction. Watch for questions that contain the answer you hope to hear.
  • Social-desirability bias Participants soften criticism to be polite, especially face to face with the person who built the thing. Make it easy to be negative (“what would stop you from using this?”), and weight what they do — the unprompted question, the wince — over what they say.
  • Confirmation bias You will hear the comments that support your idea more loudly than the ones that undercut it. Write the falsifiable hypothesis before the round, have the note-taker log disconfirming reactions verbatim, and review the dead and confused reactions before the enthusiastic ones.
  • Pitch creep Once you start selling, you stop listening. The moment you catch yourself explaining a feature unprompted, you have shifted from researcher to salesperson and the participant’s answers shift with you. Stop and ask a question instead.
  • Imagined-future bias Asking how someone would feel about a hypothetical feature produces unreliable answers. Give them something concrete to react to, and watch what they actually do with it.
  • Selection bias Interviewing whoever is easy to reach — friends, your existing network, the most enthusiastic responders — produces feedback that does not generalize. Re-screen every participant for the actual problem and the target segment before booking time.

Next Steps

  • If the solution resonates, build a minimum viable product or run a Pre-Sales Test.
  • If reactions are lukewarm, iterate on the solution and re-interview using Customer Discovery Interviews.
  • Run a Card Sorting to separate must-have from nice-to-have features from interview feedback.
  • Use solution interview insights to write your Value Proposition Test and landing page copy.
  • Use a Demo Pitch to test whether the solution generates real purchase commitment, not just positive interview feedback.
  • Run a Landing Page Test to evaluate whether the value proposition language from interviews converts strangers who have never spoken with you.
Learn more

Case Studies

ProductPlan: 30 interviews before writing code

ProductPlan ran 30 customer-validation interviews with product managers across company sizes before writing any code, and recommends a baseline of at least 10 problem-discovery and 20 product-validation interviews.

Read more

Further reading

Got something to add? Share with the community.