How to Test a Customer Problem Before Building a Product
Test a customer problem before building by running three checks in order, with pass lines written in advance: confirm from records how often it happens, price the current workaround from the account's own figures, then ask the budget owner for a paid or dated step. This suits founders selling to business buyers who can reach a dozen or so accounts. The main constraint is the small sample, so results guide a decision without establishing demand.
The result this process should produce
This guide is for founders at the idea-to-validation stage who have already chosen one problem to test and need the order of work. When the question is which of several candidate problems to pursue, use Is Your Startup Solving a Problem People Will Pay to Fix? instead. When it is the wider build, narrow or stop decision across buyer, offer and evidence, start with Validate a Startup Idea Before Building. This guide covers the run itself: what to do first, where to stop and what to write down.
The process should leave you with one short test file for one problem: the pass lines you wrote before the first conversation, one row per account, and a dated decision to build a first version, narrow the segment or stop. It separates a frequent inconvenience from a paid problem by making each account clear three gates in order. Frequency comes first because it costs a question and a look at a record. Workaround cost comes second because it takes longer and needs access to figures. A request for money or scarce time comes last because it is the hardest thing to ask for and it is easier to price once the cost is known.
The U.S. Small Business Administration's market research guide says direct research can be time consuming and expensive, and it lists in-depth interviews among the direct methods. A gated sequence limits that spend, because an account that fails an early gate does not get the later and more expensive work.
Write the test file before the first conversation
- Problem statement. One sentence: who has the problem, in what situation, and what it costs them when it happens.
- Segment. One kind of account, narrow enough that the answers can be compared.
- Intended price. A yearly figure, even a rough one, because the second gate compares against it.
- Test window. A start date and a stop date.
- Pass lines. For each gate, how many accounts must clear it and what counts as clearing it.
For the number of accounts, Hennink and Kaiser's systematic review of saturation studies reports that studies using empirical data reached saturation within a narrow range of 9 to 17 interviews, mainly in homogeneous populations with narrow objectives. Saturation tests when interviews stop adding new information, not whether anyone will pay. So a dozen or so accounts in one narrow segment is a reasonable working size for seeing the pattern of a problem. It does not estimate a market, and a mixed list needs more.
Prepare problem frequency
The first gate asks whether the problem happens often enough and whether anyone can show it. Run it in this order with each account:
- Ask when the problem last happened and what happened next. A date and a sequence of events are harder to inflate than a general impression.
- Ask how many times it happened in a defined period, such as the last full quarter.
- Ask to see whatever records it: a ticket queue, a dispatch sheet, a service log or a calendar. How to do this without selling is covered in How to Run a Customer Interview Without Pitching.
- If no record exists, ask the account to keep a simple tally until the test window closes. A completed tally is stronger than a remembered count, and whether anyone bothers to keep it tells you something too.
- Tag the entry as said, seen, done or assumed, using the tags in the Customer Interview Notes Template for Founders.
An account clears the first gate when its count is seen or done and at or above the pass line. A said entry stays open. Keep the count, because the second gate multiplies by it. Set the line from what one occurrence is likely to cost, so that a rare but expensive problem is not thrown out by a line set for a cheap, common one. Accounts that fail here leave the test: there is little point in costing a workaround for a problem nobody can date.
Work through cost of the current workaround
The second gate prices what the account does today, because that is what your product will be compared with. The SBA guide frames the pricing question as 'What do potential customers pay for these alternatives?' Answer it from the account's own figures:
- Take the last occurrence from the first gate and walk through it step by step: who did what, for how long, and what money went out.
- Put each item on one of three lines: money paid, paid hours that would actually be cut or reassigned, and revenue lost. Time from someone who is on shift regardless goes on a separate line that does not count.
- Ask to see a record for the largest item, such as an invoice, a payroll line or a customer credit.
- Multiply the cost per occurrence by the frequency to get a yearly figure, and compare it with your intended yearly price.
- Show the budget owner the figure and ask where it is wrong. A correction from the person who carries the cost is worth more than your estimate.
An account clears the second gate when the yearly figure, with its largest item seen, is above the price by the margin you set in advance. Set a margin rather than a bare comparison, because changing how work gets done costs effort too. An account whose workaround costs less than your price saves money by keeping it, however annoying it is.
Resolve willingness to commit money or time
The third gate replaces stated interest with a completed step. Murphy and colleagues' meta-analysis of stated preference valuation studies covers 28 studies and reports a median ratio of hypothetical to actual value of 1.35, with severe positive skewness in the distribution. Those studies are not startup sales and the figure is no conversion benchmark, but the direction matters: what people say they would pay tends to run above what they pay when the money is real.
So the test ends with a real request, made to the person who controls the budget:
- Make it specific: what the account gets, what it costs, when it starts and what will be measured. Be plain that the product does not exist yet and that any manual work is manual.
- Ask for something that costs the buyer something: a paid pilot, a signed order with a start date, or dated time with the approver plus access to the records.
- Set the date by which the step has to be done.
- Mark it done only when it has happened: money received, order signed, meeting held. A promise stays said.
- Record refusals and silence in the same row. They are results.
Daniel's go-to-market mentoring page describes validating a customer problem 'directly with buyers rather than with surveys' and lists this among the work of a session: 'Define a pilot outcome, a buyer commitment and the decision that follows the pilot.' Those are self-reported descriptions of his method.
The problem severity scorecard for a test run
Keep one row per account, with a value and an evidence tag in each gate cell. Unlike a comparison between candidate problems, this sheet is filled in order from the first gate to the third and stops where the account stops, so a blank is a result. The table states what each gate records and what you have to decide in advance.
| Gate | Record per account | Clears when | Does not clear | Pass line to set in advance |
|---|---|---|---|---|
| First: frequency | Date of the last occurrence, count in the period, evidence tag | The count is seen in a record or done in a tally, at or above the line | A general impression with no date | How many accounts, at what count per period |
| Second: workaround cost | Yearly figure, largest item, who carries the cost, evidence tag | The yearly figure is above the price by the margin, with the largest item seen | A founder estimate, or hours from staff on shift regardless | How many accounts, at what multiple of the yearly price |
| Third: commitment | Step requested, date set, date completed, who completed it | The budget owner completes a paid or dated step by the date | Praise, a demo request, a free trial or a promise to pass it on | How many budget owners, completing which step |
Read severity from where most accounts stop:
- Stop at the first gate. The problem is rare or undocumented in this segment.
- Stop at the second gate. The problem is real but cheap: a frequent inconvenience.
- Stop at the third gate. The cost exists, but the buyer, the offer or the timing does not move anyone yet.
- Clear all three. The problem looks paid for this segment, on this sample.
A hypothetical test with party rental companies
The following is a hypothetical example with invented details. It illustrates the method and does not describe a real company, customer or measured result.
A founder plans load-checking software for owner-run party rental companies at an intended price of $120 a month, or $1,440 a year. The problem to test: a truck leaves short of tables or chairs, and someone has to drive back with the missing items. Before the first conversation the founder writes down a four-week test window, 12 accounts and three pass lines: at least 6 accounts with a seen record of 2 or more short deliveries a month in the busy season; at least 4 accounts with a seen yearly cost of at least twice the price, or $2,880; and at least 3 budget owners paying $300 for a 30-day manual pilot within the window.
At one company the founder watches the owner stand beside a stack of round white tabletops with a hand on the pile and count it again before loading, because the last truck left two tables short. The founder then asks to see the dispatch notes for the past year.
| Gate | Result | Against the line |
|---|---|---|
| First: frequency | 10 of 12 owners named a last occurrence; 7 showed dispatch notes with 2 or more short deliveries a busy month | Clears: 7 against 6 |
| Second: workaround cost | A typical account has 3 short deliveries a busy month over 8 busy months, or 24 a year. Each costs 2 paid driver hours at an assumed $30 an hour ($60), $20 of van cost and an average $70 customer credit, or $150. That is about $3,600 a year. Of the 7 accounts, 5 showed figures above $2,880; at the other 2 the owner drives and gives no credits | Clears: 5 against 4 |
| Third: commitment | Of the 5 owners asked, 2 paid $300, 1 booked a meeting with a business partner and then cancelled, and 2 said to call back after the season | Fails: 2 against 3 |
The founder does not lower the line to 2. The row shows a pattern: both owners who paid run 3 or more trucks, while the other 3 run 1 or 2 and can often see a short load themselves. The decision is to run the 2 paid pilots as learning, narrow the segment to companies with 3 or more trucks, write new pass lines for 6 more budget owners and build no software until that run clears. The assumptions go in the file with the decision: that the dispatch notes record every short delivery, that $30 an hour is a fair driver cost, that a $300 pilot says something about paying $1,440 a year, and that truck count is the cause rather than a coincidence across 2 accounts.
Acceptance criteria and the next action
Read the run against the lines you wrote, then choose one action and date it:
- All three lines met. Move to the smallest first version for the accounts that committed, and check it against Does Your Interview Evidence Justify Building an MVP?
- Third line missed, with a pattern among those who committed. Narrow the segment or change the offer, write new lines and rerun the third gate.
- Third line missed, with no pattern. The cost is real but nobody is acting on it. Stop, or look for the event that makes it urgent.
- Second line missed. Treat it as a frequent inconvenience. Drop it as a product, or keep it as a possible feature of something else.
- First line missed. Stop, or change the segment. If you could not reach the accounts at all, that is an access problem and not a result about the problem.
One rule protects the test: a pass line changes only before the run starts. If the results suggest a different line, write it down as a new test with a new window.
Common mistakes and limits
- Running the gates out of order. A pilot request made before the cost is known has no price to stand on.
- Writing the pass lines after the first calls. By then they describe what you have already heard.
- Counting a said entry as seen. A remembered number stays said until someone shows a record.
- Taking commitment from a user. A user who promises to raise it with the owner has committed only their own time.
- Reading a small pass as demand. It is a reason to take the next step, not a measurement of the market.
The method has limits. With a dozen or so accounts, a pass is a judgment and not a statistical finding. It suits business buyers with an identifiable budget owner better than consumer products, where purchase and usage data say more than interviews. The gates, pass lines and reading rules are an editorial framework, not a measured result.
Related guides and next step
- Comparing candidate problems side by side: Is Your Startup Solving a Problem People Will Pay to Fix?
- The wider build, narrow or stop decision: Validate a Startup Idea Before Building
- Deciding whether the evidence justifies a first build: Does Your Interview Evidence Justify Building an MVP?
Daniel's go-to-market page says the first session is free and takes 30 minutes. Book a startup mentoring session and bring the test file, including the pass lines and the rows that failed, to review your problem validation decision with your actual evidence and constraints.
Frequently asked questions
How do you test a customer problem before building a product?
Write pass lines first, then run three checks in order with each account: see a record of how often the problem happens, price the current workaround from the account's own figures, and ask the budget owner for a paid or dated step. Stop an account at the first check it fails, and decide from the lines you wrote in advance whether to build a first version, narrow the segment or stop.
What evidence should a founder collect for problem validation?
For each account: the date of the last occurrence and a count over a defined period; a yearly workaround cost with its largest item checked against a record; who carries that cost; and the step the budget owner was asked for, with the date it was completed. Tag each entry as said, seen, done or assumed, and keep refusals and blanks in the record.
What are common mistakes in problem validation?
Writing pass lines after the first conversations, counting a remembered estimate as a record, asking for a pilot before the cost is known, taking commitment from a user who does not control the budget, and lowering a line when results fall short.
How many accounts do you need to test a customer problem?
A dozen or so accounts in one narrow segment is a reasonable working size for seeing a pattern, and a systematic review of saturation studies found a similar range of interviews, mainly in homogeneous populations. That shows whether the problem looks paid in that segment. It does not estimate the size of a market or establish demand.
Sources
- Market research and competitive analysis (Plan your business guide), U.S. Small Business Administration
- Sample sizes for saturation in qualitative research: A systematic review of empirical tests (Hennink and Kaiser, Social Science and Medicine)
- A Meta-analysis of Hypothetical Bias in Stated Preference Valuation (Murphy, Allen, Stevens and Weatherhead, Environmental and Resource Economics)
- Go-to-Market Mentor and GTM Strategy Advisor