Is Your Startup Solving a Problem People Will Pay to Fix?
Your startup is solving a paid problem when accounts already spend money or paid hours working around it, the yearly cost of that workaround is clearly above your intended price, and the person who controls the budget commits money or scarce time to a test. For founders choosing between candidate problems before building, score each on frequency, workaround cost and commitment. Frequency alone points to an inconvenience. The main constraint is evidence from too few accounts.
The choice and its business consequences
This guide is for founders at the idea-to-validation stage who keep hearing about a problem in conversations and have to decide whether it is worth building for, or who are choosing between two or three candidate problems before committing time or capital. The broader build, narrow or stop decision is covered in Validate a Startup Idea Before Building, and the questions that surface purchases and approvers are in customer discovery questions that reveal buying intent. This guide covers an earlier choice: whether the problem itself is one people pay to fix.
The two kinds of problem look alike in interviews. A frequent inconvenience comes up in almost every conversation, people describe it with feeling, and they agree that a fix would be nice. A paid problem may come up less often and with less drama, but the account already spends money or paid hours on it, and the person who controls the budget can say what it costs. Building for the first produces a product people like and do not buy. Building for the second gives the first offer a price the buyer can compare with something they already pay.
The consequences are lopsided. Choosing an inconvenience costs months of building and a pipeline of friendly accounts that do not convert. Setting aside a paid problem because it seemed rare costs less, because it can be revisited when buyers bring it up again. When in doubt, the evidence has to show cost, not just complaints.
The U.S. Small Business Administration's market research guide lists pricing among the questions market research should answer and phrases it as 'What do potential customers pay for these alternatives?' It also lists in-depth interviews among the ways to ask customers directly. The scorecard below turns that pricing question into evidence for one problem at a time.
Problem frequency
Frequency is the dimension founders hear most clearly and overweight most often. Ask each account when the problem last happened and how often it happened in a recent period, then look for a record: a ticket queue, a service log, a calendar or a list of incidents. A dated last occurrence that the account describes is a said entry, and a log you have looked at is a seen entry, in the terms of the customer interview notes template.
Frequency on its own does not make a problem paid. A problem that happens many times a day but costs seconds each time, handled by someone who is paid to be there anyway, adds up to little that anyone would buy back. Frequency works as a multiplier: it turns a cost per occurrence into a cost per year, and it tells you how often the buyer will notice whether your product works. Record it per account as a count over a defined period so it can be multiplied in the next step.
Watch for two distortions. People tend to overstate how often irritating events happen and understate events they have learned to absorb. And a problem that is rare for each account but predictable, such as an annual inspection or a seasonal peak, can still be paid if each occurrence is expensive. In that case frequency tells you when to sell rather than whether.
Cost of the current workaround
Every account that has the problem already does something about it, even if that means tolerating it. Your product will be compared with that workaround, not with nothing. Cost it in three parts for a defined period: money that leaves the business, such as contractor fees, refunds, spare parts or another tool; paid hours spent on the workaround; and revenue lost while the problem lasts. Ask to see the records behind these figures rather than accept an estimate.
Paid hours need care. If staff time is part of the cost, price it at what the hour costs the employer, not only the wage. The Bureau of Labor Statistics Employer Costs for Employee Compensation release reported that employer compensation costs for private industry workers averaged $46.89 per hour worked in June 2026, of which wages and salaries averaged $32.82 and benefit costs $14.07. That is a national average across occupations, so use the account's own rates where you can. The point is that a wage alone understates what an hour of workaround costs the employer.
Then separate time that is actually freed from time that is not. Minutes spent by someone who would be on shift regardless are real, but no budget pays for them, because removing them saves money only if the hours can be cut or put to other paid work. Count them, but keep them on a separate line from money spent and from hours that would be cut. Finally, compare the yearly workaround cost with your intended yearly price. If the workaround costs less than the price, the account saves money by keeping it, however annoying it is.
Willingness to commit money or time
Cost on paper becomes a paid problem only when the person who controls the budget gives something up to test a fix. Agreement, praise, a request to see a demo when it is ready and a free trial cost the buyer nothing. Commitments that do cost something include a deposit, a paid pilot, a signed order with a start date, a meeting scheduled with the approver, access to the records that show the cost and staff time set aside for a test.
Time commitments count when they are scarce and dated. An owner who blocks an hour next week to walk through incident logs has committed. One who says to call back next quarter has not. Check who made the commitment as well: a user who promises to take it to the owner has committed only their own time. How to reach the approver without selling is covered in how to run a customer interview without pitching, and what to do when buyers agree and then go quiet is covered in when customer interviews say yes but nobody buys.
Daniel's go-to-market mentoring page says a session works through naming the user, the budget owner and the event that makes the problem urgent, and defining a pilot outcome, a buyer commitment and the decision that follows the pilot. That description is self-reported on his site.
The problem severity scorecard
The scorecard records one candidate problem across all the accounts you have spoken to. Fill in one copy per problem, so that two candidates can be compared side by side. For each dimension, mark the strength as weak, moderate or strong, and tag the evidence behind it as said, seen, done or assumed. A dimension backed only by said or assumed entries cannot score strong.
| Dimension | Question to answer | Weak: points to an inconvenience | Strong: points to a paid problem | Evidence that counts |
|---|---|---|---|---|
| Frequency | How often does it happen per account in a defined period, and when did it last happen? | Common, but nobody can date the last occurrence or show a record | A regular rhythm the account can date or show in a log | A log, queue, calendar or incident list you have seen |
| Cost per occurrence | What does one occurrence cost in money, paid hours and lost revenue? | Minutes from someone who is on shift regardless | Money leaves the business or paid hours are added | Refunds, invoices, overtime or lost sales in the account's records |
| Current workaround | What does the account do now, and what does that cost over a year? | A free workaround people tolerate | A paid contractor, tool, hire or overtime that costs more per year than the intended price | A contract, invoice or payroll line you have seen |
| Who carries the cost | Does the cost land on the person who controls the budget? | Spread across users and invisible to the budget owner | The budget owner names the cost without prompting | The budget owner's own account, matched with a record |
| Commitment | What did the budget owner give up to test a fix? | Praise, a request for a demo link or a free trial | A deposit, paid pilot, signed order or dated time with the approver | Done: the step was completed, not promised |
Read the scorecard as a pattern, not a sum. Four outcomes cover most cases:
- Paid problem. Cost and commitment are strong, and the yearly workaround cost is clearly above the intended price. Test a priced offer with the accounts that committed.
- Frequent inconvenience. Frequency is strong, but cost, workaround and commitment are weak. Drop it as a product, or keep it as a feature inside a product that solves a paid problem.
- Costly but rare. Cost per occurrence is strong and frequency is weak. Look for the event that makes the problem predictable, and test with accounts about to face it.
- Untested. Most entries are said or assumed. Collect seen and done evidence before choosing, because the scorecard has not measured anything yet.
A worked decision with explicit assumptions
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 wants to build software for owner-run laundromats and has interviewed ten owners. Two problems came up. Problem A: customers phone or ask the attendant whether machines are free and when a load will finish. Problem B: a washer or dryer stops mid-cycle, or a coin jams in a machine, and nobody notices until a customer complains or the owner does the next round. At one store the founder watches the owner kneel in front of a washer that stopped mid-cycle, wet towels pressed against the round glass door, and pull a jammed coin out of the slot with needle-nose pliers while the customer waits for a refund. The owner then shows a service log with that month's incidents and a repair technician's invoice.
The founder fills in one scorecard per problem and puts them side by side:
| Dimension | Problem A: machine availability questions | Problem B: stopped or jammed machines found late |
|---|---|---|
| Frequency | 15 to 30 questions a day per store, said by all ten owners | 3 to 6 incidents a month per store, seen in service logs at six stores |
| Cost per occurrence | Under a minute of an attendant who is on shift regardless | A refunded cycle and lost machine revenue of about $25, plus about 1.5 hours of the owner's time to drive in and diagnose |
| Current workaround | Answer the phone or glance at the floor; no money spent at any store | Owner rounds plus a repair technician; call-out invoices seen at four stores, about $150 a month at a typical store |
| Who carries the cost | The attendant; no owner named a cost | The owner, who named it without prompting at seven stores |
| Commitment | 7 of 10 owners would use an app; none agreed to a paid test | 3 owners paid a $200 deposit for a 60-day pilot; 1 introduced the founder to the repair technician |
| Verdict | Frequent inconvenience | Paid problem, to be tested with the three pilot stores |
The founder then costs Problem B for a typical store and writes each assumption down. At four incidents a month, refunds and lost machine revenue come to about $100 a month. The owner's time comes to about six hours a month, and at an assumed $40 an hour for the owner's time that is $240. One technician call-out a month adds $150. The total is about $490 a month, or about $5,880 a year, against an intended price of $99 a month, or $1,188 a year. Problem A, by contrast, takes about ten minutes of attendant time a day at about 20 questions of 30 seconds each, or about five hours in a 30-day month. Even valued at the attendant's full hourly cost, no owner would cut a shift because of it, so solving it saves no money.
The decision is to pursue Problem B and drop Problem A as a product; machine availability may return later as a feature inside the monitoring product. The founder writes down the assumptions with the decision: that the six stores with seen logs are typical of the segment, that $40 an hour is a fair value for an owner's time, that the three owners who paid deposits will pay full price after the pilot, and that a retrofit sensor can detect a stopped machine on the models these stores run. The pilot outcome, set before it starts, is whether the owners' service logs show fewer stoppages found late and less driving time over the 60 days.
Common mistakes and limits
- Counting mentions instead of costs. A problem everyone mentions can still be cheap for each of them.
- Pricing hours at the wage. Hours that would not be cut save nothing, and hours that would be cut cost the employer more than the wage.
- Accepting the founder's estimate of the workaround. An estimate is an assumed entry until the account confirms it from its own records.
- Treating a free trial as commitment. It measures willingness to try, not to pay.
- Scoring a problem from users alone. If the budget owner has not seen the cost, the problem has no budget yet.
The method has limits. With a handful of accounts any score is a judgment and any verdict is a hypothesis for the next round of conversations, 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. Some problems are paid for to avoid a rare large loss rather than a running cost, and a yearly average can understate how buyers weigh them. The scorecard, its levels and its outcomes are an editorial framework, not a measured result.
Related guides and next step
- The broader build, narrow or stop decision: Validate a Startup Idea Before Building
- Questions that surface purchases, workarounds and approvers: Customer Discovery Questions That Reveal Buying Intent
- Recording each conversation with evidence tags: Customer Interview Notes Template for Founders
- Deciding whether the evidence justifies a first build: Does Your Interview Evidence Justify Building an MVP?
Bring one scorecard for each candidate problem, and the records behind it, to a free 30-minute strategy session to review your problem validation decision with your actual evidence and constraints.
Frequently asked questions
Is your startup solving a problem people will pay to fix?
It is when accounts already spend money or paid hours on a workaround, the yearly cost of that workaround is clearly above your intended price, and the person who controls the budget has completed a step that costs something, such as a deposit or a paid pilot. Frequent complaints and praise for the idea do not show that on their own.
What evidence should a founder collect for problem validation?
For each account: when the problem last happened and how often, with a log if one exists; what one occurrence costs in money, paid hours and lost revenue; what the current workaround costs over a year, from the account's own records; whether the budget owner can name the cost; and the strongest step the budget owner completed. Tag each entry as said, seen, done or assumed.
What are common mistakes in problem validation?
Counting how many people mention a problem instead of what it costs them, pricing staff time at the wage or counting hours that would not be cut, accepting the founder's estimate of the workaround cost, treating a free trial as commitment, and scoring the problem from users who do not control the budget.
How is a frequent inconvenience different from a paid problem?
A frequent inconvenience happens often but costs little each time, usually minutes from someone who is paid to be there anyway, and its workaround is free. A paid problem already costs the account money or paid hours that the budget owner can name, and that owner is willing to give up money or scarce time to test a fix.