
A solution interview is a meeting where you show your fix to someone who has the problem, watch them use it and ask for a real commitment. It comes after problem interviews, once you have something to show: a clickable prototype, a demo or an early version.
This is the fifth and last guide in our customer development series. The problem interview checklist tells you whether the problem is real. This guide tells you whether your solution is the one people will pay for.

Problem interview vs solution interview
| Problem interview | Solution interview | |
|---|---|---|
| Goal | Learn which problems hurt and how often | Check that your fix works and that people will commit |
| When | Before you build anything | When you have a prototype, demo or MVP |
| What you show | Nothing | The product, the flow and the price |
| Questions | About the past | About the solution in front of them, plus a direct ask |
| A good result | A ranked list of problems | A pre-order, a signed pilot or a clear “no” |
In a problem interview, you never mention your idea. In a solution interview, you can finally ask direct questions, as long as they’re about the thing on the screen and not about some future version.
Are you ready for solution interviews?
Run them when two things are true:
- Problem interviews found one problem that scores high and comes up often in one customer group.
- You have something people can try, such as a prototype or a demo.
In 2026 that “something” costs little to make:
- A clickable prototype of the main flow, made in a design tool. It looks like the product and takes days to make.
- A beta build on real phones. Apple’s TestFlight lets you invite up to 10,000 external testers, including through a public link. Your first build has to pass App Review for TestFlight before they get it, so allow time for that review.
- A demo with sample data. For a B2B product, a working demo with realistic data loaded often beats a prototype.
Volumetryx, a platform for scans in cancer drug trials, is a good example. The founders had a tested idea. They wanted to show drug companies the product instead of describing it, before paying for a full compliant build. We built a working demo of the whole flow in about a month of weekly sprints, with a sample trial already loaded so their sales team could demo from the first click.
The three-part script
| Minutes | Part | What you do |
|---|---|---|
| 0-10 | Problem | Remind them of the problem in their own words from the last interview. Ask if anything has changed. |
| 10-35 | Solution | Hand them the prototype and give them a task. Watch. Don’t explain unless they’re stuck. Then ask the questions below. |
| 35-45 | Agreement | Make a direct ask: a pre-order, a pilot, an introduction or another meeting. |
The hardest rule is in the middle part: don’t pitch. You’re there to find the weak spots, not to win an argument. If you catch yourself explaining why a screen makes sense, the screen doesn’t.
Solution interview questions
Does it solve the problem?
- How would this change the way you handle [the problem] now?
- When would you use it? Walk me through the last time you’d have needed it.
- What’s missing for you to use it next week?
- What should not be in it? What would put you off?
- How would you describe this to a colleague?
Price and value
- What does this problem cost you now, in money or time?
- Here’s the price. Does it match what you’d save?
- Who would approve the purchase, and is there a budget for it?
Avoid questions about a future version, such as “Would you buy it once it has X?” People say yes to end the awkward moment. Ask about the minimum instead: “What’s the least this needs to do for you to pay for it?”
From a polite yes to a real commitment
A compliment isn’t a commitment. Ask for something that costs the person time, reputation or money. The higher on this ladder they climb, the more you can trust the yes.
| Commitment | What it costs them | What it tells you |
|---|---|---|
| Another meeting with a real task to try | Time | Mild interest |
| An introduction to their boss or the budget holder | Reputation | They’ll spend credibility on it |
| Telling three colleagues or friends about it | Reputation | They think others need it |
| A signed letter of intent or a pilot agreement | Reputation, legal time | A B2B buyer is serious |
| A pre-order or a deposit | Money | Demand backed by money |
| A paid pilot | Money and time | The strongest signal before launch |
Taking a pre-order is easy now. A Stripe payment link costs nothing extra on standard pricing; you pay the usual 2.9% plus a fixed fee per card payment. If you take money for something that doesn’t exist yet, say clearly when it will ship and how to get a refund.
If people won’t commit at any level, ask what’s missing. If the answers point to a different problem or a different group, that’s a signal to change direction, not to polish the prototype.
How many commitments are enough?
Work it out from your own numbers. Your unit economics tell you how many paying customers cover the build. Then ask whether your solution interviews found a believable share of them.
Here’s an example run of our estimate’s math with sample inputs for a B2B SaaS web app. The inputs are assumptions, not data: $99 a month per customer, an 80% margin, 24 months a customer pays, $600 to win a customer and 15 new customers a month. With those guesses, the build comes to $6,600 to $13,600 over 5 weeks. Each customer brings $79 a month in profit, or $1,296 over their lifetime after the cost of winning them, so 8 customers pay for the build ($10,100). The first month that earns more than it spends is month 8, and the build is paid back in month 16.
In that example, finding 8 companies willing to sign a paid pilot is a fair test of the plan. Finding 2 tells you to look again at the price or the customer group before you build.
This step matters because it catches both of the big killers. In CB Insights’ March 2026 study of startups that shut down since 2023, 43% of those with a known reason cited poor product-market fit and 19% cited unit economics that didn’t work. A solution interview with a price on the table tests both.
How we would estimate this
Our project estimate turns your brief into user stories. You confirm what’s in scope, and every hour in the budget traces back to a story you kept. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. It’s a planning range, not a fixed quote.
For market size, it suggests customer groups and gives each one a TAM, SAM and SOM with a note on what the number covers. Treat them as hypotheses to test, not verified demand. The unit economics show how many customers pay for the build and in which month it’s paid back, and you can change any starting number. Put in the price people accepted in your interviews and watch the payback month move. You can estimate your MVP’s cost and timeline in about four minutes.
What we would do
- Start from the top problem your problem interviews found. Write it in the customers’ words.
- Build the cheapest thing people can try: a clickable prototype or a demo with sample data. Our UI/UX design team makes an MVP design with a clickable prototype tested with people from your audience, for $5,000-11,000 in 3-5 weeks.
- Go back to the people from your problem interviews first. They already know the problem.
- Run the three-part script. Don’t pitch. Count what people do, not what they say.
- Make a direct ask in every meeting, and log where each person stops on the commitment ladder.
- Compare the commitments with the number of customers who pay for the build. If they add up, build the first version: our MVP development typically costs $5,000-15,000 and takes 2-4 weeks. If not, go back to the hypothesis log.
Short on money for this stage? The small-budget guide compares the cheaper tests.
FAQ
What is a solution interview?
A meeting where you show a prototype, demo or early version to someone who has the problem, watch them use it, ask about it and ask for a commitment such as a pre-order or a pilot.
What is the difference between a problem interview and a solution interview?
A problem interview comes first and shows nothing: you learn which problems hurt. A solution interview comes later: you show your fix and test whether it works and whether people will commit to it.
What should you show in a solution interview?
The cheapest thing people can try for real: a clickable prototype of the main flow, a beta build on their phone or a working demo with sample data. A slide deck isn’t enough.
How do you know if a solution interview went well?
The person tried the product, found a weak spot you can fix and agreed to something that costs them time, reputation or money. Compliments alone mean it didn’t go well.
How many solution interviews do you need?
Enough to find as many committed customers as your numbers say will pay for the build. Start with 10 in one customer group and keep going until the commitments add up, or clearly don’t.