Chapter 7

The Paid Problem Test

Economic Pain Changes Behavior

When a problem becomes expensive enough, people start doing things about it. Not necessarily smart things, or efficient things. But things. They create spreadsheets. They add approval steps. They hire somebody, or assign part of somebody else’s job to it. They build an internal script that only one employee understands and everyone is afraid to touch. They pay a contractor. They tolerate a process that requires six clicks, three exports, and one person named Kevin who knows what to do when the numbers do not match.

That behavior interests me more than the complaint. A person saying, “This process is terrible,” gives me one kind of information. A company assigning four people to keep that process from failing gives me another. The second signal is not proof that your app will sell; it says nothing about trust, price, or timing. But it tells you the problem has crossed a threshold. Somebody is paying for it now. They may not call it software spend. It appears as wages, overtime, rework, delay, missed revenue, management attention, or the opportunity cost of experienced people doing work they would rather not do. The money does not have to leave the company for the cost to be real.

This is why I prefer observed behavior to adjectives. People are generous with adjectives. A workflow is “awful,” a task is “painful,” the existing tool is “a nightmare.” Sometimes those words describe a serious problem. Sometimes they describe the software equivalent of an uncomfortable office chair. The intensity of the language is not a reliable pricing model.

Suppose two managers tell you that preparing monthly client reports is one of the most frustrating parts of their operation. The first spends an hour at the end of each month cleaning up a spreadsheet, dislikes it, and has complained about it more than once. The second has five account managers assembling reports by hand, two senior employees reviewing them because mistakes have reached clients before, a checklist created to reduce errors, a tracking sheet added because the checklist did not reveal which reports were still outstanding, and a manager who now spends part of Friday afternoon chasing status. Both can accurately say, “I hate this process.” Only one of those sentences is surrounded by evidence. The second company has already allocated labor, added controls, and accepted recurring coordination cost, probably one reasonable decision at a time. Commercially meaningful pain leaves debris behind.

Time savings need the same scrutiny. “Save five hours a week” sounds commercially powerful, and sometimes it is. But five hours of whose time, and what happens to those hours today? If an owner spends five hours every week on work they cannot avoid, those hours may matter a great deal. If the wasted time falls in a low-value administrative period and nobody has a realistic alternative use for it, the economic effect is smaller than the arithmetic suggests. A calculator can multiply hours by salary. It cannot tell you whether the organization cares. Has anyone tried to reduce the time already? Has the company added staff because of it? Does the work get escalated when it falls behind? Does the problem appear in budgets, client complaints, performance targets, or deadlines? Those actions tell you the organization is not merely experiencing the problem. It is absorbing consequences from it.

Builders naturally focus on what the product changes: how much faster the workflow is, how many steps disappear, how accurate the automation becomes. The commercial comparison starts one step earlier, with what the buyer was already doing because the problem existed. That shift can make a technically modest improvement look valuable, or an impressive one look weak. An app that cuts a task from thirty minutes to five sounds excellent; if the task happens once a year, the improvement is pleasant and economically unimportant. An app that cuts a task from thirty minutes to twenty is much less impressive technically; if the task happens sixty times a day across a team and delays another workflow when it runs long, ten minutes matters enormously. The product delta is smaller. The consequence is larger. We are trained to admire the size of the improvement. Buyers care about the size of the consequence, which is a different measurement.

It also explains why some ugly processes survive for years. Their ugliness is not evidence that nobody cares. Often the process is ugly because people kept adding compensating behavior to stop an important problem from getting worse: another spreadsheet, another review, another person copied on the email, another Friday afternoon sacrificed to the ritual. From the outside those workarounds look like incompetence. Commercially, they may be the strongest evidence you have, because they show what the buyer is already willing to sacrifice. The next place to look is therefore not at the complaint. It is at the workaround.

Existing Workaround as Evidence

One of the first things I want to know about a supposedly painful problem is what people are doing about it now. Not what they wish they could do. What they are actually doing. If a company has assigned employees to it, bought another tool, built an internal process, hired a contractor, or accepted some other recurring cost, the problem has already caused an allocation decision. That does not mean the allocation is intelligent. Some of the most interesting opportunities begin with a workaround nobody particularly likes.

Early in my career, I worked on a team building an internal operations application for a large company. It was the kind of application developers tend to appreciate. We pulled information from several systems, cleaned up a process that had accumulated years of workarounds, and replaced a mixture of spreadsheets, manual reconciliation, and email threads with something considerably more coherent. The demos went well. People liked the application, review meetings generated ideas, and users asked for features. And yet actual usage remained sporadic.

That was uncomfortable because the product appeared to solve a real problem. Our mistake was paying attention to the visible inconvenience and not to the structure underneath it. When we finally sat down with the operations leader responsible for the team, he did not care about half the things we had spent time building. What he cared about was that senior analysts were spending hours each week manually reconciling exceptions, that mistakes created rework, and that managers could not tell where a request was stuck. Those were not annoyances in a workflow. They were operating consequences.

So instead of treating the product as a generally better system, we narrowed the rollout around one high-volume workflow, measured how the existing process behaved, automated what could be automated, created a clear exception path for cases that still needed human judgment, and showed the manager the difference. The technical product did not become brilliant at that moment. What changed was that we finally understood what the existing process was costing the organization. The spreadsheets had been evidence. The manual reconciliation had been evidence. The senior analysts spending time on exceptions had been evidence. We had been looking directly at the workaround without appreciating what it told us. The project moved into broader use, and the manual reconciliation required for that workflow fell substantially. The narrow lesson is not that every messy process deserves software. It is that the workaround revealed where the organization was already paying.

Founders often look at an ugly workaround and assume the ugliness itself creates the opportunity. “We’re replacing spreadsheets.” Maybe. Spreadsheets have supported an impressive number of profitable companies despite decades of software founders announcing their elimination. The spreadsheet is not the signal. What matters is what the spreadsheet is doing. One maintained for five minutes every other month is one thing. One touched by seven people every day, reconciled against three systems, reviewed by a manager, and used to prevent billing errors is something else. Same file extension, different economic meaning.

The same applies to every common workaround. A prospect tells you employees review every transaction by hand. How many transactions? How long does it take? Who performs it? What happens when something is missed? If one employee spends fifteen minutes a week checking something for reassurance, you have one kind of problem. If a team of skilled analysts spends half its day reviewing transactions because an error creates regulatory exposure, you have another. Contractors are especially revealing: if a company regularly pays an outside person to do the job your product automates, someone has already decided the outcome is worth money, and the conversation begins in a very different place. You are no longer arguing that the problem deserves resources. You are asking whether there is a better way to deploy resources already in use. Existing software spend works the same way. A team that complains about the system it pays $20,000 a year for is more interesting than a team that complains equally loudly about a task with no budget, no significant labor, and no consequence when it goes wrong. The category has already passed a budget test inside that organization.

The workaround tells you the buyer has responded to the problem. It does not tell you they want your response. Founders skip that second half because finding an ugly process produces such a satisfying feeling; you discover twelve spreadsheets and a weekly reconciliation meeting and the business case seems to write itself. Sometimes it does. Sometimes those twelve spreadsheets are embedded so deeply that replacing them would require six months, four integrations, security approval, and the cooperation of three departments that stopped speaking to each other during a reorganization in 2022. A costly workaround can signal a valuable problem. It can also signal a difficult replacement. Both facts belong in the analysis.

A problem with no workaround may still become commercially important; regulations appear, technologies create new risks, and problems emerge before organizations respond. But when a mature problem has existed for years and nobody has spent meaningful time, money, or effort on it, I become cautious. Perhaps nobody has found the right solution. Or perhaps the buyer has already revealed what the problem is worth by repeatedly choosing not to spend much on it. That is why I do not look at workarounds merely as competitors. I look at them as evidence of what the buyer has already decided.

The Paid Problem Test

I have spent several sections making the word pain considerably less convenient. That is intentional. I do not want you leaving a customer conversation thinking, “Good news, they hate this,” and treating that as the commercial conclusion. Hatred is interesting. It is not a budget.

I call what follows the Paid Problem Test, with one clarification up front: passing it does not mean somebody will pay you. I wish it did; this would be a much shorter book. The test answers a narrower question. Is this problem occurring under conditions where paying to solve it could be rational? That is different from whether the product is good, whether the buyer likes your solution, whether your price is right, or whether the person will commit. Those come later.

Take one specific buyer and one specific problem. Not “marketing agencies waste time on reporting.” A real agency, or at least a clearly defined buyer situation you can investigate. Then work through six questions.

1. What happens if the problem continues? Begin with the consequence. If nothing changes, what happens next week, next month, next quarter? Does somebody spend more time, does work get delayed, does revenue arrive later, does a customer wait, does the organization accept more risk? Or does everyone simply remain irritated? That last answer is allowed. Sometimes the commercially useful conclusion is that the problem is real and the consequence is small, which can save a remarkable amount of engineering.
2. What is the buyer already doing because the problem exists? Look for behavior: spreadsheets, assigned employees, a contractor, another product, an internal tool, a review step, a recurring meeting, an escalation path. If the answer is “nothing, really,” do not automatically kill the idea; new problems appear before workarounds do. But notice what you do not have. You do not have behavioral evidence that solving this has been important enough to consume resources, and that should affect your confidence.
3. What does the current response consume? Do not settle for “they do it manually.” How much time, whose, how often? What tools are paid for? What rework occurs? What waits? What happens when volume increases? You are trying to understand the size and shape of the sacrifice the buyer is already making. Do not manufacture precision. If a process occupies several hours of senior staff time each week, that may be enough to justify investigating further. Approximate truth is more useful than precise fiction.
4. Who owns the consequence? This is where the previous chapter connects to this one. The person performing the frustrating work may not be the person for whom the problem is economically important. An analyst hates the reconciliation. The operations manager owns the backlog. The finance leader owns the delayed billing. The founder of a small company owns all of it, because small companies have an organizational structure best described as “whoever notices the fire first.” Find the person whose staff, budget, risk, deadline, or performance is affected. You are not necessarily looking for the contract signer yet. You are looking for the person who can say, in substance, “If this keeps happening, it affects something I am responsible for.”
5. Why does it matter now? What changed? Did volume increase, is someone leaving, did a customer complain, is a deadline approaching, has hiring been frozen, did the problem recently fail in a way that made it visible? Sometimes there is no trigger. The company has tolerated the problem for seven years and appears perfectly capable of reaching eight. Write that down. You are not trying to persuade yourself that urgency exists. You are trying to discover whether it does.
6. Is doing nothing still a reasonable decision? I like this question because it removes the founder from the center of the analysis. Imagine you are the buyer. You understand the problem, the current cost, the imperfect workaround, and the consequence. Would a sensible person still leave things alone? Sometimes yes. The problem costs $5,000 a year, but changing systems would consume $20,000 of effort and real risk. The team has excess capacity and more important priorities. The platform is being replaced next year anyway. A founder hears these answers and thinks the buyer “doesn’t get it.” The buyer may understand perfectly. Doing nothing is an alternative, and frequently a strong one.

There is no magic score. Four yes answers do not mean “validated” while three mean “pivot”; that kind of precision would make the framework look more scientific while making the thinking less honest. Look at the pattern instead. Suppose you are investigating reporting software for an agency. The account managers say reporting is annoying; that alone is weak. Five account managers each spend several hours on it every month; more interesting. Senior employees correct mistakes before reports reach clients; stronger. A manager keeps a tracking spreadsheet because reports are frequently late; stronger again. The agency recently added several large clients, volume is rising, and the owner has told the manager not to add administrative headcount this quarter. Now we have a different situation. Have we proved they will buy your software? No. We have not tested the offer, the price, trust, or commitment, and we do not yet know whether your software solves the problem well enough. What we have established is that the problem deserves a serious commercial experiment.

Compare that with an agency where the owner prepares three reports once a month, spends about ninety minutes, dislikes the work, and has followed the same routine for six years without trying to change it. Your application might still delight that owner. But if I had limited time and needed to decide which buyer deserved the next conversation, I know where I would start. That is what the test is supposed to change: not your ability to describe pain, but your allocation of attention. If the six questions produce mostly assumptions, you have not failed the test. You have identified what needs investigation. If they reveal recurring labor, spend, risk, delay, executive attention, and a current reason to act, you have something substantially better than a persona with a pain point. You have a plausible paid problem. Plausible still matters, because it is possible to find a problem that looks excellent under this test and still discover that the business goes nowhere.

Better Discovery Questions

Founders are very good at asking questions that produce encouraging answers. “Would this save you time?” Probably. “Would it be helpful if this were automated?” Sure. “Would you use something that made this easier?” Why not? These questions are not useless because people are dishonest. They are weak because they ask someone to imagine a better situation without making the existing situation compete against anything. You have asked me to compare my current irritation with an imaginary improvement that costs nothing, takes no time to adopt, requires no approval, and works exactly as described. The imaginary product has excellent unit economics.

Discovery gets more useful when you stop asking people to predict their enthusiasm and start asking them to explain their current behavior. Suppose you are building software that automates a recurring report. You could ask, Would an automated reporting tool be useful to your team? The buyer may sincerely say yes, and you have learned that automation sounds useful. Now try, Walk me through what happened the last time you produced the report. That question has somewhere to go. Who started it? Where did the information come from? How long did it take? Who reviewed it? What went wrong? Was it late, and who noticed? You are no longer collecting adjectives about a category. You are reconstructing an event, and people are much better at describing what happened than predicting what they would do. I would rather hear, “Last Thursday three of us stayed late because the client numbers did not reconcile,” than, “Reporting is one of our biggest pain points.” The first gives me something to investigate. The second leaves me to find out what biggest means.

Shift from asking whether something is important to asking what happens when it fails. Instead of How important is this process? ask What happens when it is late? or What happens when nobody does it? “Nothing much, we send it the next morning” is useful. “We cannot invoice until it is complete” is also useful. Those two organizations may describe the inconvenience in identical language. Their consequences are radically different.

Ask what the buyer has already tried. What have you done so far to make this better? exposes both seriousness and history. Maybe they bought a tool, wrote scripts, hired someone, redesigned the process twice, or built a spreadsheet and decided that was sufficient. Maybe the answer is “nothing.” Do not rush past that. Ask why. Perhaps the problem only recently became serious, or every solution has been too expensive, or nobody owns it. Or perhaps it has been around for five years and nobody has cared enough to act, which deserves more weight than another enthusiastic answer to “Would automation help?”

Ask about tradeoffs rather than value. What are you not doing because this takes time? is better than How much is your time worth?, which practically begs for artificial ROI. “Honestly, nothing important, I do it Friday afternoon” tells you the time savings are real without being economically powerful. “My senior account managers lose most of a day they could spend with clients” tells you something you can investigate. The same applies to money. Do not begin with How much would you pay to solve this? People are notoriously generous with money they are not currently being asked to spend. Start with What does this cost you today? The answer may not be a dollar figure; it may be two employees, a contractor, overtime at month-end, or several hours of management review. Good. You are learning the current economic environment rather than asking the buyer to invent a price for your product.

Then ask who notices. When this goes wrong, who hears about it? reveals more about authority than “Who is the decision-maker?” The person doing the work says their manager gets involved when the backlog grows. The manager says the CFO asks about it in monthly reviews. The CFO says it is irritating but not remotely important enough to fund this year. Excellent. You are finding the edges of the problem. Discovery should make the opportunity more precise even when precision makes it less attractive, and that is the part founders resist. We enter the conversation hoping for confirmation. The better goal is to reduce uncertainty. If I believe agencies will pay to automate reporting, I should want to discover that most agencies consider the process trivial, if that is true, or that the real problem is correcting inconsistent data before reporting, or that the employee complaining most loudly has no influence over the purchase. Commercially unpleasant information can prevent months of beautifully executed work on the wrong theory.

There is one question I would be especially careful with: Would you buy this? It is tempting because it appears to skip to the answer we want. But before the person has seen the actual offer, price, implementation burden, and risks, it still asks them to imagine a future decision under favorable conditions. You may hear yes. Do not throw it away. Just do not spend it yet.

The better progression is to understand what is happening now, what it costs, who owns the consequence, what has been tried, why it might matter now, and what makes leaving it alone reasonable, and then to put something real in front of the buyer: a product, an evaluation, a price, a pilot, a commitment. That is where the evidence changes again. The Paid Problem Test cannot prove that someone will purchase your app. It can help you stop spending equal attention on every person who says they have a problem, because some problems are complaints, some consume resources, some block revenue, and some become urgent only under particular conditions. Your job is to determine which you are looking at.

Then comes the question founders understandably want answered most. What counts as demand? A buyer can have a real problem, under expensive conditions, with a credible reason to act, and still tell you, “This is exactly what we need.” “I’d definitely use this.” “Keep me posted.” Those statements feel much closer to a sale, and they are closer. They are still not the same thing. The next step is learning how much evidence each one deserves.