Before a “looks great” counts as fit
Solution Interview Script — Write the Tripwire Before the First Show
A pitch plus a polite yes is confirmation bias. A solution interview happens after the problem is already evidenced, and it tests whether this proposed artifact — a mockup, a wireframe, a scripted walkthrough, a thin demo — actually fits the job. Write the tripwire before the first show so Sunday cannot promote “looks great” into fit evidence.
Last updated: October 3, 2026
Direct answer
What is a solution interview?
A solution interview is the second Customer Development test: after the problem is evidenced, you show a specific proposed solution and watch whether the person can do the named job with it. Steve Blank’s 30 November 2009 post “Customer Development is Not a Focus Group” is blunt about what the work is — and is not. Customer Development tests two founder hypotheses: first, the customer problem; second, whether the product concept and minimum feature set solve that problem. Gathering a feature list, running a survey, or holding a focus group is not Customer Development. This page is the second test, written as a tripwire — observable signal, threshold, calendar window, named action — dated before the first show. Fill your own N. Do not invent a typical count.
Key takeaways
What to remember
- A solution-interview tripwire is four fields: fit-signal + threshold + calendar window + named action. A compliment is not the signal.
- Problem first. Blank’s sequence is the problem hypothesis, then whether this product concept and minimum feature set solve it. A solution show with no evidenced problem is a pitch.
- Prefer behavior over praise: walkthrough friction, completing the named job with the artifact, a named next commitment short of money. “Looks great” does not fire the tripwire.
- Write the tripwire before the first show. A bar invented after warmth is a recap, not a test.
- Scores do not prove fit. Matching pre-written behavioral signals does. Fill your own N. This page publishes no conversion rate.
Why it matters
A polite yes after a pitch cannot tell you what failed
I have watched founders treat six “this looks amazing” walkthroughs as proof the mockup fits. Nobody completed the job on the artifact. Nobody named the step that still forced last week’s workaround. The build still opened — and the first thin version was shown to people who had never evidenced the problem. Steve Blank’s 2009 point is the one this page keeps: Customer Development is not a feature harvest. You are testing a founder hypothesis about the problem, then a founder hypothesis about whether this product concept and minimum feature set solve it. Alex Osterwalder (Strategyzer, 17 January 2018) names the sequencing trap: if you lead with the solution and get a rejection, you cannot tell whether the problem was wrong or the solution was wrong. CB Insights’ 2026 analysis of 431 VC-backed companies that shut down since 2023 is useful here as a warning about fit — not as a personal forecast. “Ran out of capital” leads their list at 70 percent, and they are explicit that this is often the final cause of death. Among the 385 companies with identifiable reasons, more telling patterns include poor product-market fit (43 percent), bad timing (29 percent), and unsustainable unit economics (19 percent). Many shutdowns cited more than one reason, so those shares can add to more than 100 percent. Building a thin product for a polite audience is a fit problem. It does not show up in compliments. This page does not invent other percentages, and it does not claim a solution interview predicts survival.
Vocabulary
What counts as a solution-interview signal
A solution interview is not a demo with extra slides. It is a sitting where a named person tries to complete a named job with a specific artifact, after the problem is already evidenced. Each card below needs a log a stranger could read. A compliment, a feature request, or a “I would use that” is how a pitch becomes “we have fit.”
1. The problem is already evidenced
A recent incident and a workaround exist in their words, from a problem interview or equivalent notes — not from the pitch you are about to give. If you still cannot name last week’s scene, this is the wrong page. Strategyzer’s rule is the same: jobs, pains, and gains first. Otherwise a “no” later cannot be read.
2. Observed walkthrough friction
They try the artifact. You watch where they pause, skip, ask you to take over, or invent a step you did not draw. Log the minute and the step. “Seemed engaged” is not friction. Silence while they complete the job is data too.
3. They can complete the named job with the artifact
The job is one sentence you wrote before the sitting. They finish it on the mockup, wireframe, scripted walkthrough, or thin demo without you narrating the punchline. If you have to click for them, the artifact did not carry the job.
4. A named next commitment short of money
A calendar hold to retry the same job on a real Tuesday, an intro to the person who actually does the work, or leaving the artifact with a named operator who will try it once. Not a deposit, not a pre-order, not a checkout — those belong on the WTP page. Not “send me the deck.”
5. What does not count
“Looks great.” “I’d use that.” A feature list they invented after your pitch. A waitlist. A smoke or fake-door click. A Yibud score. Those can sit in the notes. They do not fire this tripwire.
The tripwire
Signal, threshold, window, action — written before the first show
The artifact tells you what you are testing. The tripwire tells you what happens if the artifact does not fit in time. Do not skip a field. The counts you later write are yours. They are not a benchmark copied from this page.
Field 1 — Observable fit-signal
A stranger could log that a named person completed the named job on the artifact, with friction notes, and made a next commitment short of money. “Loved the mockup” is not a signal.
Field 2 — Threshold
N of M qualified sittings produce a fit-signal. Qualified means the problem is already evidenced for that person — last week’s incident and a workaround in the notes. Fill N and M yourself. This page does not publish a usual pass bar or a typical solution-interview count.
Field 3 — Calendar window
Start date and end date. Fourteen days from the first show is a window. “We’ll keep demoing this quarter” is not. Silence inside the window is a no on this filter.
Field 4 — Named action
Stop this artifact, rewrite the job-sentence or the artifact, or Continue to the next cheapest test (a money tripwire, a design-partner ask, or a thinner problem pass). Hope is not an action.
Field 0 — Written before the first show
If the four fields appear after the first “looks great,” you wrote a recap. Date the page in the same sitting you name the artifact. A kinder bar later is a new page with a reason — not an edit after warmth.
Not the same page
Solution interview vs Mom Test, discovery, smoke, delivery, WTP, design partner, earlyvangelist, beta, and decision contracts
Several Yibud pages sit next to this one. Mixing them up turns a pitch plus a polite yes into “the solution fits,” or a click into a completed job.
Mom Test and customer discovery — problem side, no pitch
Those pages ask about last week’s life and refuse a polite yes. They are how the problem becomes evidenced. This page starts after that evidence exists, and it shows a specific artifact. “Would you use this mockup?” is a Mom Test fail if it is the whole sitting. Mention Mom Test here only as the problem-side method — that script has its own page.
Smoke test and fake-door — uncharged reach
Those pages measure whether anyone reaches. They are usually uncharged. A click is not a completed job on an artifact. Use them when you still cannot find the person. This page starts when the expensive unknown is whether this proposed solution fits a job you already have evidence for.
Concierge and Wizard of Oz — delivery
Those pages own how you produce the outcome by hand, or behind a curtain. A solution interview can sit before a concierge week. Delivery answers “can we produce the result?” This page answers “does this artifact fit the job we already evidenced?”
Willingness-to-pay — money moving
That page’s signal is a deposit, pre-order, paid concierge, or priced checkout. This page’s next commitment is short of money: a retry on a real Tuesday, an intro, an artifact left with a named operator. Do not count a solution-interview pass as WTP, and do not count a checkout as fit.
Willingness-to-pay test →Design partner — scarce co-dev, not a walkthrough
That page’s signal is staff time, data, workflow access, and weekly use as Customer Validation evidence. Completing a job on a wireframe is not a signed partner. A design partner can later sit on a solution-interview artifact. The labels are not interchangeable.
Design partner validation →Earlyvangelist — who-filter, not the artifact
That page’s signal is matching Blank’s five characteristics — problem, awareness, search plus timetable, cobbled workaround, budget path. This page is whether a named artifact fits a named job. An earlyvangelist can later sit a solution interview. Matching the five is not a completed walkthrough.
Earlyvangelist validation →Beta testers — usage testers, not a first-show fit test
That page is how to find people who will run the unfinished product and tell you what broke. A beta tester can be quiet, unpaid, and still useful. A solution interview is a short, scripted sitting against a pre-written fit bar. Do not recruit twenty testers and call two walkthrough compliments a solution-interview pass.
How to find beta testers →Kill, pivot, pre-mortem, assumption, decision — contracts
Kill and pivot pages write Stop or rewrite tripwires. A pre-mortem ranks failure modes. Critical-assumption names one claim. The validation-decision page reads a week of evidence you already have. This page supplies fit-evidence those contracts can later read. It is not a Stop / Pivot / Continue sitting.
A mid-band customer, solution, or monetization score is a flashlight, not a solution-interview pass. It can point at a weak “this artifact fits the job” assumption. It does not complete the walkthrough. What a validation score actually means →
The sitting
How to write and run a solution-interview tripwire in one sitting
Do this after problem notes already name a weekly incident and a workaround — not after you have already spent the week pitching the mockup to everyone who would take a call. Set a timer. Leave the build closed. If you have a co-founder, each of you writes a draft alone, then you keep the stricter bar.
- 1
Write the evidenced problem as one sentence
Person + job + last week’s incident + the workaround they already run. “A clinic front-desk lead who spent forty minutes on a paper intake packet for a returning patient last Tuesday.” If the sentence still says “users hate paperwork,” you do not have a problem bet yet. Stop and run the Mom Test or discovery page first.
- 2
Name the artifact and the job it must complete
One artifact: a clickable wireframe, a paper mockup, a scripted walkthrough, or a thin demo. One job the artifact must carry without you narrating. “Check in a returning patient and print the day’s forms.” If the job is “see if they like it,” you are still pitching.
- 3
Name whether fit is the expensive unknown
If the problem is not evidenced, run discovery or the Mom Test first. If you still cannot find anyone in the job, run smoke or fake-door. If the unknown is price, write a WTP tripwire. If the unknown is scarce access, write a design-partner tripwire. If the unknown is “will this artifact carry the job,” stay on this page.
- 4
Write the signal a stranger could log
“Named person completes the job on the artifact, with friction notes, and books a second sitting or leaves the artifact with a named operator.” Not “loved the design.” Blank’s second hypothesis is whether the product concept and minimum feature set solve the evidenced problem — not whether the slides landed.
- 5
Write a threshold, a window, and the action
Threshold: “fewer than N of M qualified sittings produce a fit-signal by day D.” Window: start date and end date. Fourteen days from first show is a window. Action: Stop this artifact, rewrite the job-sentence, or Continue to the next cheapest test. Fill N and M yourself.
- 6
Date the page, then show — do not pitch first
Same sitting. Sign it. Take the job-sentence and the log fields into the room. Open with the last incident they already told you, then hand them the artifact. Do not lead with “would you use this?” If you later want a kinder bar, that is a new page with a reason — not an edit after the first compliment.
What you leave with
The Solution-Interview Contract (copy this)
If the sitting produced a mood, you did not finish. The page should have one filled tripwire and log fields you would actually use. Fill the brackets. Leave nothing as “users,” “the demo,” or “soon.”
The tripwire
Problem already evidenced: [person / job] who [last incident] and already runs [workaround]. Artifact: [mockup / wireframe / scripted walkthrough / thin demo]. Job the artifact must complete: [one sentence]. Signal: named person completes that job on the artifact (friction logged) + a next commitment short of money ([calendar retry / intro / artifact left with named operator]). Threshold: [N of M qualified]. Window: [start]–[end]. Action if miss: [Stop this artifact / rewrite job-sentence / run a named cheaper test].
If any bracket still says “users,” “traction,” or “later,” the contract is not written. Qualified means the problem is already evidenced for that person. Compliments do not count toward N.
What does not count as the signal
Not a signal: a compliment, “looks great,” “I’d use that,” a feature list after the pitch, a waitlist, a smoke/fake-door click, a beta signup, a discovery call with no artifact, a Yibud score. Optional later: a money tripwire or a design-partner ask is a different page, written on its own.
You may still take notes on praise. You may not let praise fire the tripwire. Completing the named job fires the tripwire. Money moving is the WTP page.
Example tripwires (templates — fill your own N)
Fit: if fewer than N of 6 qualified front-desk leads complete “check in a returning patient” on the wireframe by day 14 → rewrite the job-sentence the same day. Friction: if they cannot finish without you clicking → do not count them. Next step: if they will not book a second sitting or leave the artifact with a named operator → signal incomplete, even if they praised the screens.
The counts are blanks for you to fill. They are not conversion rates, not Yibud results, and not a claim about what “usually” happens. There is no typical N on this page.
The fork
When the solution interview is the expensive unknown — and when it is not
This page decides only whether “this artifact fits a job we already evidenced” is the unknown you should buy evidence for now. Problem interviews, money, scarce commitment, reach, delivery, and usage testers have their own pages. Do not show a mockup to a problem you cannot name.
Run the solution interview first
The problem is evidenced. You can name last week’s incident and the workaround. The expensive unknown is whether this artifact carries the job. Write the tripwire. Show it. Log friction. Do not start with “would you use this?”
Run WTP or design-partner first
The artifact already carried the job in a logged sitting. The unknown is whether they will pay this price — or put time, data, and workflow at risk. Use the WTP page or the design-partner page. Do not relabel a walkthrough as money or as scarce commitment.
Run discovery or the Mom Test first
You cannot yet name the job, or the only evidence is a compliment you collected while pitching. Interviews are cheaper than a solution show with no problem behind it. Osterwalder’s trap is the one to avoid: a solution-first rejection cannot tell you which hypothesis failed. Come back here once the problem is evidenced and “does this artifact fit?” is the unknown.
When a solution-interview tripwire is the expensive unknown
The job is named. A weekly incident exists without you prompting it. You have a mockup, wireframe, scripted walkthrough, or thin demo. You do not know whether a named person can complete that job with it. That is this page. A weak solution or customer line on a Yibud report sits near this fork — as a flashlight, not as a fit count.
When a solution-interview tripwire is the wrong next test
You cannot name the job. You are still asking “would you use this?” in the same breath as the pitch. Or you only needed reach, a usage tester, a scarce-commitment partner, or a charge. Run the interview filter, the reach test, the beta playbook, the design-partner ask, or the money tripwire first. A solution show with no evidenced problem is theater.
Worked example
One solution-interview contract you can copy (illustrative)
The week below is illustrative — names, clinics, and counts are invented so you can see the setup. It is not a conversion benchmark and not a Yibud report. Copy the method, not the numbers.
The fit-bet, written before the first show
“A pediatric clinic front-desk lead who spent at least forty minutes last Tuesday on a paper intake packet for a returning patient, and who already runs a clipboard-plus-scanner workaround.” The tempting next step is to automate the whole intake stack. The current bet assumes the front-desk lead is the person, last Tuesday’s packet is the job, and a clickable wireframe is the instrument. Problem notes already exist from earlier talks — this sitting is not a first discovery call. Illustrative names: founder Mei Chen at Intakekit; candidate Dana Ortiz at Harbor Pediatrics.
The tripwire, written the same sitting
Signal: named front-desk lead completes “check in a returning patient and print the day’s forms” on the wireframe without the founder clicking, friction logged by step, and either books a second sitting on a real Tuesday or leaves the artifact with a named operator who will try it once. Threshold: fewer than 2 of 6 qualified front-desk leads produce that package by day 14. Qualified means last week’s packet is already in the notes — not that they “work at a clinic.” Window: first show through day 14. Action if miss: rewrite to a narrower job (returning patients only, one form) or Stop this artifact. Compliments do not count.
What a miss looks like on day 14
Illustrative close: five leads compliment the screens; three ask for a feature list; one finishes the walkthrough only after Mei clicks every step; zero book a second sitting; zero leave the artifact with an operator. That is a solution-interview miss you already named — rewrite the job-sentence or Stop. It is not a reason to start the intake engine “because people were warm.” A waitlist in the same week would have looked busier. That list is reach, not fit.
What must not happen in the window
Do not count “looks great” as completing the job. Do not skip the next-commitment field because the walkthrough was smooth — Blank’s second hypothesis is whether the concept solves the evidenced problem, not whether the slides landed. Do not ask “how much would you pay?” and treat a yes as this page’s signal — that is the WTP page. Do not stretch day 14 because the sixth lead has not replied — silence is a no on this filter. If you cannot find six qualified front-desk leads in fourteen days, you may have a reach problem — that is a discovery or smoke-test tripwire, not a reason to fake a fit-pass.
Write the tripwire before the first show. If day 14 arrives and no named person completed the job on the artifact, honor the action. If it moved against the bar you wrote, Continue to the next cheapest test — a money tripwire or a design-partner ask, not a factory. The method is the dated page, not the story you tell after.
Where Yibud fits
Use the free validator as a flashlight, then write the fit-contract yourself
Yibud is a free, no-signup startup idea validator. Scores come from a deterministic rule engine, not from a language model guessing success. Optional AI text, when it is used, only polishes prose. It does not invent the number. A Startup MRI report can name a weak customer, solution, or monetization assumption, then a Day-7 Continue / Refine / Re-test / Stop signal. Solution-interview work sits next to a weak “this artifact fits the job” assumption — write the fit-tripwire, do not hope a mid-band score means “the mockup will land later.” If you already have a report, start the contract with the named assumption — not with the overall score. Then run the window yourself. The method stands alone if you never open the analyzer.
Analyze my idea →Common mistakes
What usually wastes the solution-interview contract
Running a pitch and counting a polite yes as fit
Blank’s second hypothesis is whether the product concept and minimum feature set solve an evidenced problem. “Looks great” is manners. If the only evidence is warmth, you have talk. You do not have a tripwire firing.
Showing the artifact before the problem is evidenced
Osterwalder’s sequencing trap: lead with the solution, get a no, and you cannot tell whether the problem was wrong or the solution was wrong. Run the Mom Test or discovery first. A solution show with no last-week incident is a focus group with slides.
Harvesting a feature list and calling it Customer Development
Blank’s 2009 post exists because that move wasted years of chip design. Any idiot can collect “can it also do X?” Customer Development tests the founder’s hypothesis. A longer feature list after a walkthrough is not a fit-signal.
Relabeling WTP, a design partner, an earlyvangelist, or a beta tester as this sitting
Money moving is the WTP page. Scarce co-dev is the design-partner page. Blank’s five characteristics are the who-filter. A usage tester reports breakage. Completing a job on a wireframe is none of those. Do not use a compliment or a signup list to skip the fit-contract.
Writing the bar after the first show — or using a score as the count
A fit-list invented after warmth is a recap. A miss you already named, followed by a new repo, is how the bar moves. Honor Stop or rewrite the job-sentence. A Yibud score does not complete the walkthrough. Fill N yourself.
Sources
Where these ideas come from
- Steve Blank, “Customer Development is Not a Focus Group” (November 30, 2009) — Used for what Customer Development tests: (1) the founder’s hypothesis about the customer problem, and (2) whether the product concept and minimum feature set solve that problem. Gathering feature lists, surveys, or focus groups is not Customer Development. The time to iterate the product is if and only if customers show the problem hypotheses are wrong or name missing features that would cause them not to buy. This page does not invent a sample size from the post.
- Steve Blank, Customer Development category — Used as light primary context for the Customer Development posture after the problem is evidenced: leave the building, talk to people who have the job. This page does not invent quotes from the category archive.
- CB Insights, “The top 9 reasons startups fail” (report analyzing 431 VC-backed shutdowns since 2023; updated March 5, 2026) — Used as a warning about why fit and unit economics matter, not as a personal success forecast. CB Insights reports “ran out of capital” at 70 percent and calls it often the final cause of death. Among the 385 companies with identifiable reasons, more telling patterns include poor product-market fit (43 percent), bad timing (29 percent), and unsustainable unit economics (19 percent). Many companies cited more than one reason. This page does not invent other percentages.
- Alex Osterwalder / Strategyzer, “Problem vs Solution In Customer Interviews” (January 17, 2018) — Used for sequencing only, with no invented numbers: test customer jobs, pains, and gains before leading with the solution. If you lead with the solution and get a rejection, you cannot tell whether the problem was irrelevant or the solution was no good. Customer discovery is not selling. This page does not treat the workshop exercise as a conversion benchmark.
In one paragraph
Summary you can quote
A solution interview is a pre-written fit tripwire: an observable signal, a threshold, a calendar window, and a named action, dated before the first show. It starts after the problem is already evidenced. The signal is behavioral — walkthrough friction, completing a named job with a mockup, wireframe, scripted walkthrough, or thin demo, and a next commitment short of money — not a compliment or a feature list. Steve Blank’s 30 November 2009 post “Customer Development is Not a Focus Group” says Customer Development tests the founder’s hypothesis about the customer problem, then whether the product concept and minimum feature set solve it; gathering feature lists is not Customer Development. Alex Osterwalder (Strategyzer, 2018) warns that a solution-first rejection cannot tell you which hypothesis failed. Mom Test and discovery own the problem side; smoke and fake-door own uncharged reach; concierge and Wizard of Oz own delivery; WTP owns money moving; design-partner pages own scarce co-dev; earlyvangelist pages own the who-filter; beta pages own usage testers; kill, pivot, pre-mortem, critical-assumption, and validation-decision pages are decision contracts. This page supplies fit-evidence those contracts can later read. Scores do not prove fit. A Yibud report can point at a weak solution assumption. The tripwire still has to be written by the founder.
FAQ
Questions founders actually ask
What is a solution interview?
A sitting after the problem is evidenced, where a named person tries to complete a named job with a specific artifact — mockup, wireframe, scripted walkthrough, or thin demo. Blank’s 2009 post: Customer Development tests the problem hypothesis, then whether the product concept and minimum feature set solve it. This page writes that second test as a tripwire.
How is this different from a Mom Test or customer-discovery interview?
Those pages stay on last week’s life and refuse a pitch. This page starts after that evidence exists and shows a proposed solution. “Would you use this?” is still a fail. Completing the job on the artifact is the signal. The Mom Test script has its own page; this page does not replace it.
How many solution interviews do I need?
Fill your own N. This page does not publish a typical count, a conversion rate, or a “usual” pass bar. Write N of M qualified sittings inside a dated window before the first show. A miss you already named is a miss.
Does a compliment or “I’d use that” count?
No. Those are manners. Log them if you want. They do not fire the tripwire. Completing the named job, with friction notes, plus a next commitment short of money, does. If money moving is the expensive unknown, write a WTP tripwire.
Do I need an account, and where does Yibud fit?
You do not need an account. The method on this page stands alone. Run the free analyzer if you want a flashlight on a weak solution or customer assumption before you write the contract. The engine is deterministic. Optional language-model text only polishes prose. Bring the named assumption back here and fill the brackets.
Write the fit-tripwire before the next sprint
Yibud scores weak solution and customer assumptions with a deterministic engine. You write signal, threshold, window, and the log fields while you are still honest — then a solution interview is evidence, not a polite yes.
Generate a Yibud report →