Run solution interviews before building

Why this matters

Problem interviews proved the pain; solution interviews test whether YOUR answer fits it, before you build. Showing five prospects a mockup surfaces wrong assumptions in an afternoon that would otherwise cost a development cycle. The trap: this is where polite lies concentrate, so method matters.

What "done" looks like

• 5 sessions with people from your validated segment (ideally past interviewees)
• A clickable mockup or storyboard walked through end to end
• Notes on where they leaned in, hesitated, or got lost
• Each asked a commitment question, and their reactions recorded

How to do it

1. Prepare a thin prototype: 4 to 6 screens of the core flow (Figma or even slides). Polish invites compliments; sketchiness invites correction, stay sketchy.
2. Reset context first: "Last time you told me [their problem]. We made a first attempt at solving it, tear it apart."
3. Let THEM drive. Ask "what would you do on this screen?" instead of touring features. Silence is your best tool.
4. Probe the workflow fit: "Where would this live in your day? What would it replace? Who else needs to say yes?"
5. End with commitment, not compliments: "If this existed next month at $X, would you use it? Can I put you on the pilot list?" A yes-with-conditions is data; "looks great!" alone is nothing.

Common mistakes

• Demoing proudly for 20 minutes and calling the nods validation
• Testing on new people with no problem context, feedback about UI, not fit
• Skipping the price question to keep the conversation comfortable

Real-world examples

• Dropbox's famous validation was essentially a solution interview at scale: Drew Houston posted a demo video of how the product would work, before the sync engine was built, and the beta waitlist reportedly jumped from around 5,000 to 75,000 overnight, proving demand for the solution, not just the problem.
• Rob Fitzpatrick's The Mom Test is the standard playbook here: when you show a mockup, watch what people actually do and ask about their past behavior instead of fishing for "would you use this?" compliments, which even friendly prospects hand out freely.
• Treat these as a bridge between problem and build, do them after interview 10 potential customers and use the reactions to shape your MVP feature list.

From a founder's point of view

Showing a rough mockup is uncomfortable precisely because it's useful, a real reaction to something concrete tells you far more than a polite yes to a hypothetical. The goal isn't to hear that your idea is great; it's to watch where people lean in, where they get confused, and what they ignore entirely. Five honest sessions before you write code routinely save months of building the wrong thing.

Rule of thumb

Count only behaviors: corrections, workflow objections, pilot signups, intro offers. Compliments are the sound of an interview failing politely.