Chapter 5

Find Where the Money Is Breaking

“Nobody Is Buying” Hides Too Much

Imagine two founders tell me exactly the same thing:

“Nobody is buying.”

The first founder launched six weeks ago. The product has received 140 visitors. Most came from a few LinkedIn posts, friends, other builders, and a directory listing. The founder cannot tell me how many visitors were actually plausible buyers. There have been three signups, no serious evaluations, and no sales conversations.

The second founder has had 2,000 visitors from a narrowly targeted campaign. More than a hundred people have created accounts. Forty have completed the central workflow. Twelve have used the product repeatedly. Several have told the founder that it solves the problem well.

Nobody has paid. Both founders can accurately report zero customers. They do not have the same problem.

This sounds almost embarrassingly obvious when the situations are placed beside each other. In practice, we collapse them into the same diagnosis constantly.

“We need more marketing.” “We need more traffic.” “Conversion is bad.”

“People aren’t buying.”

Those statements describe outcomes. They do not tell you what failed.

I care about the distinction because the wrong treatment can make a healthy part of the commercial system look worse while leaving the actual failure untouched. Send more traffic to the first founder and you might finally expose the product to enough qualified buyers to learn something. Send ten times more traffic to the second founder and you may simply purchase a larger sample of people who still refuse to pay.

The traffic worked differently because the failure happened at a different point.

This is familiar territory in engineering. If somebody tells you, “The application is broken,” you do not normally begin rewriting random parts of the system. You ask what broke.

Does the page not load? Does authentication fail? Does the request reach the API? Does the API return an error? Does the database contain the wrong data? Does the workflow complete but produce the wrong result?

Those distinctions determine where you investigate next. “Broken” is useful as a complaint and nearly useless as a diagnosis.

“Nobody is buying” deserves the same suspicion.

I think a lot of bad commercial advice begins by treating revenue as though it were one giant output variable. Revenue is low, therefore do marketing. Revenue is low, therefore lower the price. Revenue is low, therefore improve the landing page. Revenue is low, therefore add features.

Any of those may eventually be correct. But revenue appears at the end of a sequence of behaviors, and several different things can stop that sequence long before money is involved. You may not know who the buyer is. You may know who the buyer is but have no credible way to reach them. You may reach them and get no response.

They may respond but refuse to evaluate the product. They may try it and discover that the value is weaker than you believed. They may value it and still refuse to pay. They may pay and then leave. Those are not seven descriptions of the same marketing problem.

They are different failure states.

I call the sequence the Commercial Failure Diagnostic, which is a somewhat grand name for a practical question I wish more founders asked before changing anything:

How far toward durable payment has a buyer actually made it?

The simplified version looks like this:

cannot find buyer → no reply → will not try → tries but does not value → values but will not pay → pays but does not stay

The point is not to turn human beings into boxes in a funnel diagram. Real buying behavior is messier. A prospect can move backward, disappear for three months, involve another person, return after a budget change, or reject you for reasons they cannot explain cleanly themselves.

The diagnostic is useful because it forces us to locate the last thing we actually know. Suppose you send fifty messages and nobody responds. You do not yet have evidence that people try the product and dislike it. You have not reached that experiment. Suppose twenty qualified prospects take a serious look, ten begin using the product, and eight tell you the result is valuable, but all eight decline when asked to pay $500 a month.

You no longer have permission to describe the whole thing as an awareness problem just because “awareness” would be more comfortable to fix. The buyers became aware. They evaluated. They found value. Then the commercial path broke.

That is a much narrower problem. Narrow problems are useful. They give you fewer places to hide.

This is where I think technical founders can borrow one of our better engineering habits without making the mistake of treating buyers like software. In a distributed system, we instrument boundaries because knowing that the final transaction failed is not enough. We want to know which service received the request, where state changed, which dependency returned an error, and what succeeded before the failure occurred.

Commercially, founders often instrument everything and diagnose nothing. We know the visitor count. We know the signup count. We know sessions, clicks, email opens, feature usage, trial starts, demo requests, and perhaps even the exact button somebody hovered over before disappearing forever.

Then we stand over this impressive collection of telemetry and say:

“Marketing isn’t working.” Maybe. But where? That question is the beginning of diagnosis.

A few years ago, I worked with an application that had received several hundred visitors without producing a single paid conversion. The obvious next move was advertising. The sample was small, the founder wanted more data, and more traffic seemed like the cleanest way to get it.

The logic was reasonable. It was also premature. Before paying to increase the number entering the system, we needed to know what the people already inside it were doing. That investigation ended up changing not just whether we advertised, but what we believed the problem was in the first place. And that is what a useful diagnostic should do. It should tell you which question deserves to be asked next.

Cannot Find Buyer

Some apps fail before a prospect has had a chance to ignore them.

The founder has a product, a landing page, maybe even a few users, but cannot answer a more basic commercial question with much precision:

Who is supposed to pay for this?

Not who could use it. Not who might appreciate it. Not which broad category seems compatible with the feature set.

Who is the plausible buyer? This is the first failure state in the Commercial Failure Diagnostic because everything after it depends on having a reasonably good answer. If I build a tool that analyzes meetings, I can tell myself it is for managers, consultants, salespeople, recruiters, project teams, founders, agencies, lawyers, researchers, and anyone else who spends too much of life inside a video call. That may all be technically true. Commercially, it tells me almost nothing.

Those people buy for different reasons. They experience different consequences when meetings go badly. They have different budgets, approval processes, alternatives, security requirements, switching costs, and tolerance for another piece of software.

If I put one generic message in front of all of them and nobody responds, I have not learned that the product lacks demand. I may have learned that I never formed a sufficiently specific demand hypothesis to test. This distinction matters because founders sometimes diagnose this stage as a messaging problem. They rewrite the headline. Then they rewrite it again.

They try shorter copy, longer copy, more urgency, less urgency, a new hero image, a free trial, a demo button, a waitlist, a different call to action, and eventually a sentence containing the word revolutionize against their better judgment. But copy cannot rescue a test whose subject is undefined. Before you can ask whether a message resonates, you need to know who was supposed to find it relevant.

A useful buyer hypothesis is not a beautifully formatted persona with a stock photograph and a fictional name. We will deal with that problem later. At this stage, I want something much simpler.

I want to be able to point to actual people or organizations and explain why paying is plausible. Not guaranteed. Plausible. Suppose you have built software that automatically converts messy engineering notes into structured compliance documentation. “Engineers” is not yet a buyer hypothesis.

“Small engineering firms” is better, but still loose. “Engineering consultancies that must produce a specific compliance package for every client project, currently assemble it manually, and have someone accountable for getting that package out the door” begins to describe a commercial situation I can investigate. Now I can find examples. I can look at how they work today. I can ask who owns the problem.

I can see whether the pain belongs to the engineer, the project manager, the compliance lead, or the firm owner. I can learn whether the work is irritating, expensive, risky, billable, absorbed into overhead, or simply tolerated. Most importantly, I can put the product in front of people for whom a purchase would make sense if the underlying assumptions are true. That is enough to move to the next experiment.

The bar here is not perfect customer knowledge. You do not need to discover the one sacred ideal customer profile before speaking to anyone. Early commercial learning would become impossible if that were required.

You need enough specificity that the evidence coming back means something. If I ask ten randomly selected business owners whether they want my software, their reactions may tell me very little. If I ask ten operators who currently perform the workflow my product replaces, under conditions where that workflow costs them real time or money, their reactions are much more interpretable. The product did not change. The quality of the experiment did.

One simple way to identify whether you are stuck at this first failure state is to try to make a list. Can you name ten or twenty real people or organizations that could plausibly buy the product under conditions you can explain? Not ten demographic descriptions. Not ten industries copied from a market-research report.

Not “creators,” “developers,” “entrepreneurs,” or “small businesses.”

Actual candidates. If you struggle to produce the list, that is useful information. You may not yet know enough about the buyer to diagnose anything farther down the path.

The correct response is not embarrassment. It is investigation.

Find people doing the job you believe your product improves. Look at what they use now. Look at who appears to own the problem. Look for circumstances where the problem becomes expensive enough that a purchase could be rational.

You are trying to earn the right to run a better commercial test. This is also why broad traffic can create false confidence. A thousand visitors are not necessarily more informative than twenty carefully chosen conversations. If you do not know how many of those thousand people were plausible buyers, a conversion rate can become a precise measurement of an undefined population. The number looks rigorous.

The underlying question is still vague. At this stage, resist the urge to optimize. Do not optimize the landing page for people you cannot identify. Do not optimize pricing for buyers whose budgets and alternatives you have never examined. Do not declare the onboarding broken because miscellaneous visitors did not complete it.

First determine whether you can reliably put the product in front of people who have a credible reason to care. Once you can do that, the diagnostic changes. Now you have identifiable buyers. You can reach them. You put the proposition in front of them.

And they say nothing. That silence is a different problem.

No Reply

Once you can identify plausible buyers, the next commercial test is straightforward in theory. You put something in front of them. Then nothing happens. No reply. No click.

No demo request. No rejection, either.

Just silence.

This is one of the easiest failure states to misread because silence feels like a verdict. Founders send twenty messages, hear nothing, and begin making conclusions about the product.

Maybe nobody wants this. Maybe the market is saturated. Maybe the price is wrong. Maybe I need more features. Maybe I should change the entire positioning. You do not know any of those things yet.

Silence is evidence that the path failed before a meaningful evaluation took place. It is not evidence about what would have happened after evaluation.

That distinction can save a lot of unnecessary product work. Suppose I send a cold message to the operations director of a company that appears to have the exact problem my app solves. The message gets no response. Several explanations remain possible. She never saw it.

She saw my name but did not recognize it and ignored the message. She read the first sentence and could not tell why it mattered. I described the product instead of the problem she cares about. I contacted her in a channel she rarely uses. She agrees the problem exists but does not own it.

She is the right person, but this is the wrong week. She thinks the claim sounds implausible. She already solved the problem another way. She understood perfectly and simply does not care enough to respond. Those possibilities are commercially very different.

The only thing the silence proves is that I did not earn the next step. This is why I resist language such as “the market rejected it” when the evidence consists of ignored outreach. Rejection would actually be useful. “No, because we already use X.” “No, because this is not important enough.”

“No, because our security team would never approve it.” “No, because I would pay $100 for this, not $1,000.” Those answers may be unpleasant, but they contain information.

Silence contains much less.

That does not make silence meaningless. If you repeatedly contact plausible buyers and consistently receive nothing back, something is wrong.

The diagnostic question is simply narrower than many founders make it. The problem is somewhere between identifying the buyer and creating enough relevance, credibility, or access to get a response. That is where you investigate. One mistake here is changing too many variables at once.

A founder sends forty emails. Nobody responds.

The next batch targets a different industry, uses a new message, introduces a different offer, changes the price, adds a free trial, and comes from a different domain. If responses improve, what did we learn? Almost nothing. Something in the new configuration worked better. That may be enough to feel encouraged, but not enough to build a repeatable commercial system.

The same experimental discipline that helps in software applies here. Change the hypothesis you are testing. If you believe the buyer is right but the message is too generic, change the message. If you believe the message is relevant but the channel is weak, test another access path. If you suspect credibility is the problem, introduce evidence, specificity, or a trusted connection where you legitimately have one. If you are unsure whether the person actually owns the problem, test that assumption directly.

The goal is not to become a laboratory scientist about every email. Human behavior will never give you the cleanliness of a unit test.

The goal is to stop treating all silence as one thing. This matters particularly for technical founders because our instinct is often to make the product more impressive when the market does not answer. We add a dashboard. We build an integration. We improve the AI output.

We create another automation. Then we send another message that still gives the recipient no good reason to respond. The product got better. The commercial failure stayed exactly where it was. I have also seen founders respond to silence by increasing volume immediately.

Ten messages produced no replies, so they send a hundred. A hundred produce no replies, so they automate a thousand.

There are situations where more volume is appropriate. A tiny sample can easily mislead you.

But automation magnifies whatever assumption you feed into it. If the buyer list is wrong, you contact the wrong people faster. If the message is vague, you distribute vagueness more efficiently. If the sender has no credibility and the claim sounds generic, scale does not repair that. It gives you a larger collection of people who ignored you.

Do not automate a guess. Before scaling outreach, I want enough evidence that the basic commercial proposition can cause the intended buyer to engage. The response does not have to be positive. A useful reply might be curiosity. It might be disagreement.

It might be, “You need to talk to our finance team.” It might be, “We handle that manually and it is painful, but this quarter is impossible.” Any of those gives you more information than silence. They show that the proposition reached a human being and entered consideration. That is progress in the diagnostic even if no sale follows.

So if your current evidence is no reply, stay there. Do not jump ahead and diagnose pricing. Do not redesign onboarding. Do not conclude that the product fails to create value. Do not add features in response to a buyer who has not evaluated the features you already built.

Improve the test until plausible buyers reliably engage with you in some meaningful way. Then pay close attention to what happens next. Because a reply is not a sale. Sometimes people respond. They understand the problem.

They understand what you are offering. They may even agree that it sounds useful. And they still will not try it.

Will Not Try

A response tells you that the message reached somebody. It does not tell you that the offer is strong enough to earn an evaluation.

This is the next failure state, and it is easy to miss because conversations can feel like progress. A founder gets replies, books a few calls, receives polite interest, and starts to believe the commercial system is beginning to work.

Then nobody actually tries the product. People ask questions. They say the idea is interesting. They agree the problem exists. They may even compliment the implementation.

But when the moment comes to connect an account, upload the data, install the extension, invite the team, schedule the pilot, or otherwise do the thing required to experience the value, they stop. That is not the same as no reply. The buyer has crossed one boundary and failed at the next. Now the question is not whether you can create attention. It is whether the expected value is high enough to overcome the friction and perceived risk of trying.

Every evaluation costs something.

Sometimes the cost is obvious. The buyer may need to pay for a pilot, involve IT, sign a data-processing agreement, or allocate staff time.

Sometimes the cost looks trivial to the founder and still feels significant to the buyer. Create an account. Import a file. Install an agent. Add a credit card.

Ask a colleague for access. Move sensitive data into an unfamiliar system. Change one part of a workflow that already works well enough. Technical founders routinely underestimate these costs because we know the product is safe, useful, and worth the effort. The prospect does not know that yet.

From their side of the transaction, evaluation is an investment made before the evidence exists. That makes “just try it” a much bigger request than it appears.

Imagine a tool that promises to reduce the time required to review customer-support tickets. The operations manager replies to your outreach. She agrees that ticket review consumes too much supervisor time. She likes the demonstration.

Then you ask her to export six months of customer conversations and upload them into a product built by a company she heard of twenty minutes ago. If she disappears at that point, the evidence does not say the software failed to analyze the tickets. The software never received the tickets. The path broke before product value could be tested. Founders sometimes respond by reducing friction mechanically.

Shorter signup. Fewer form fields. Google login. Sample data. A guided tour.

Those can help, but only if friction is actually the reason the buyer will not proceed. Sometimes the real obstacle is that the expected payoff is too weak. A five-minute setup can be too expensive for a problem nobody urgently wants solved. Sometimes the problem is trust. Sometimes trying the app exposes the buyer to organizational risk.

Sometimes the buyer likes the idea but has no authority to connect the systems required. Sometimes the evaluation process is simply too large relative to the decision. A company may not want a six-week pilot to determine whether a $49-a-month tool is useful. Conversely, a serious enterprise buyer may distrust a product whose entire evaluation consists of “sign up free and see what happens.” The amount and form of commitment have to make sense for the purchase being considered.

This is why a free trial does not automatically solve the will-not-try problem. Free removes one cost. It does not remove effort, risk, uncertainty, switching friction, political exposure, security concerns, or the opportunity cost of paying attention. You can price an evaluation at zero and still be asking too much. At this stage, I want to know exactly where prospective buyers stop.

Do they agree to a demo but fail to attend? Do they attend and refuse access to real data? Do they create accounts but never begin the core workflow? Do they want a pilot but will not identify an internal owner? Do they repeatedly say, “Send me the link,” and then do nothing with it?

These behaviors are more useful than the general statement that prospects seem interested. Interest is cheap. Evaluation requires behavior. That makes this stage commercially important because it is one of the first places where a buyer must spend something before you ask them to spend money. Time.

Attention. Effort. Political capital. Access. Trust.

If they will not spend any of those, you have not yet earned the right to learn whether they would spend dollars. The practical mistake is jumping ahead. A founder sees that nobody has become a paying customer and immediately starts testing prices. But if nobody has meaningfully evaluated the product, price may not be the active constraint. You are changing a variable at a stage the buyer has not reached.

Stay with the failure you can observe. Ask what the buyer believes will happen if they try. Ask what they must do to find out. Ask what could go wrong from their perspective. Ask whether the expected result is strong enough to justify that effort.

Then reduce the right friction, strengthen the right reason to proceed, or design a smaller credible evaluation. The goal is not to make every prospect try the product. Some should not. The goal is to get plausible buyers far enough into the real experience that the next evidence becomes available. Because eventually somebody does try it.

They connect the account. They run the workflow. They use real data. They give the product a fair chance to prove what you said it could do. And sometimes the result is worse than silence.

They use it. They just do not find it valuable.

Tries but Does Not Value

This is the failure state founders are often least eager to diagnose. The buyer tried the product. They got through onboarding. They used the real workflow. They gave it a fair chance.

And the result was not important enough. That is a product or value problem in a much more meaningful sense than “people are not buying.” The distinction matters because now the buyer has finally experienced what you built.

Before this point, we were mostly diagnosing access, relevance, trust, and evaluation friction. Here, the product itself enters the commercial test.

Did the promised outcome happen? Was the improvement noticeable? Did it matter? A product can work exactly as designed and still fail this test. Imagine an app that automatically summarizes long technical documents.

The summaries are accurate. They arrive quickly. The interface is clean. The user says, “This is pretty good.” Then they return to their normal process.

That reaction can be maddening because nothing appears obviously broken. There is no bug report to fix. No missing integration. No complaint about the design. The user simply does not behave as if the result matters very much.

Builders are vulnerable here because we tend to notice technical success. The model produced the correct summary. The automation completed. The report generated. The recommendation was accurate.

The system performed the task. Commercial value asks a different question. What changed for the user because the task was performed? Did they save enough time to care? Did they make a better decision?

Did they avoid a meaningful risk? Did they produce more revenue? Did they eliminate work they genuinely disliked? Did something become possible that was previously too expensive, slow, or difficult? If the answer is no, technical correctness does not rescue the proposition.

This is one reason demos can be deceptive. A demonstration compresses the experience into its most impressive moments. You control the data. You know where to click. You choose the use case.

You avoid the boring parts. The prospect sees the product under ideal conditions. Then they use it themselves and discover that the result is merely convenient. Convenience can absolutely be worth paying for. But the amount of convenience has to matter relative to the cost of changing behavior.

Saving thirty seconds on a task performed twice a month is different from saving thirty minutes on a task performed twenty times a week. The feature may be identical. The economic significance is not. This is also where founders sometimes misinterpret compliments. A user can sincerely like the product and still derive too little value from it to change behavior.

“That’s clever.” “This is really polished.” “I like what you’ve done here.” Those reactions are pleasant. They are not the outcome you were trying to create.

At this stage, behavior matters more. Does the user return without being chased? Do they complete the core workflow again? Do they introduce real data? Do they depend on the result?

Do they become irritated when the product is unavailable? Do they replace part of an existing process with it? These are not perfect measures, but they tell you whether value is becoming operational rather than merely conversational. When users try the product and do not value it, the temptation is often to broaden the product. Maybe we need more use cases.

Maybe the dashboard needs additional metrics. Maybe we should add team features. Maybe we should support another workflow. That response can make the problem worse. A weak core outcome surrounded by more functionality is still a weak core outcome.

This is where you have to be precise about what failed. Perhaps the product solves the wrong part of the workflow. Perhaps the result is too small. Perhaps the value arrives too late. Perhaps the user has to do so much work to receive the benefit that the net improvement disappears.

Perhaps the person using the product is not the person who feels the economic consequence. Perhaps the product is genuinely useful, but only under conditions that apply to a much narrower group than you originally imagined. That last possibility is especially important. A value failure does not always mean the product is bad. It may mean the market definition is too broad.

Ten people can use the same product and experience ten different levels of value because their starting conditions are different. The commercially useful question is not, “Do users like this?”

It is:

Under what conditions does this become important? Look for those conditions. Volume. Frequency. Cost.

Risk. Revenue exposure. Labor. Deadline pressure. Existing workaround.

Organizational responsibility. The differences between people who shrug and people who care can teach you more than another round of feature brainstorming. If users repeatedly try the core experience and do not change their behavior, stay with that evidence. Do not blame awareness. Do not blame pricing yet.

Do not buy more traffic to produce more people who experience the same weak result. Find out whether the outcome itself is strong enough, fast enough, and important enough for a credible buyer. And if it is not, change the product, the use case, or the buyer hypothesis accordingly. Eventually, though, you may reach a more frustrating point. People try the product.

They return. They tell you it saves time. They rely on it. They may even tell you they would be annoyed to lose it. Then you ask them to pay.

And they still say no.

Values but Will Not Pay

This is where the commercial conversation becomes uncomfortable in a different way. The buyer has tried the product. They understand it. They use it. They can describe the benefit.

They may even depend on it enough that removing access would annoy them. Then you ask for money. No. Now we have crossed an important boundary. The problem is no longer whether the product creates value at all.

The problem is whether the value is strong enough, urgent enough, economically meaningful enough, and packaged in a way that produces a purchase. Those are different questions. A useful product is not automatically a buyable product.

Builders sometimes treat willingness to pay as though it were a referendum on quality. If the product is genuinely good, somebody should pay. If nobody pays, perhaps the product is not good enough.

That interpretation is too simple. People use valuable things every day that they would not personally purchase. They use software their employer already provides. They tolerate advertisements instead of paying for premium access. They perform annoying tasks manually because the annoyance costs less than the solution.

They use a free tool because the paid improvement is real but not consequential. They happily accept a benefit when the price is zero and make a completely different calculation when a credit card appears. The value did not necessarily disappear. The decision changed. This is the stage where I want to know what exactly the buyer is refusing.

Sometimes the answer really is the price. A prospect values the product at perhaps $50 a month and you are asking $500. That is useful evidence. But “too expensive” is not always a clean statement about price.

It can mean:

I do not believe the problem costs enough to justify this. I do not have a budget for this category. I like the result, but I can continue with the workaround. I would buy this if the problem happened more often. I am not the person whose budget benefits from the savings.

I do not trust the company enough to make a long-term commitment. I cannot justify this internally. The benefit is real, but solving this problem is nowhere near the top of my list. Or, sometimes, it simply means no. This is why immediately cutting the price can be such a destructive response.

Suppose a buyer refuses your product at $200 a month. You lower it to $99. Still no. You lower it to $49. Still no.

You introduce a lifetime deal for $199 because by this point everybody is having a strange week. Still very little happens. The experiment did not prove that $200 was wrong. It may have shown that price was not the primary obstacle. A buyer who does not have a sufficiently important reason to purchase can reject almost any nonzero price. This is the commercial difference between value and economic value.

Economic value does not require that your product directly makes the buyer money. Plenty of worthwhile products improve safety, reduce frustration, save time, simplify compliance, reduce uncertainty, or make work substantially better.

But the benefit has to compete against something. The buyer is not deciding whether your product is useful in isolation. They are deciding whether obtaining that usefulness is worth the money, attention, approval, risk, and change required to get it. The existing workaround gets a vote. Doing nothing gets a vote.

Other priorities get a vote. The budget gets a vote. The person who has to explain the purchase to someone else gets a vote. This is why you can have enthusiastic users and weak monetization without either side being irrational. The founder sees hours saved.

The buyer sees a task that was annoying but already handled. The founder sees a cleaner workflow. The buyer sees another subscription. The founder sees sophisticated automation. The buyer sees something their junior employee currently does on Friday afternoon.

Both descriptions can be true. What matters is which one governs the purchase decision. At this stage, behavior around commitment becomes especially valuable. What happens when you quote a real number? Does the buyer negotiate?

Do they ask what is included? Do they ask whether you can invoice annually? Do they need approval? Do they compare the cost with an existing tool or employee time? Do they attempt to reduce scope?

Do they ask for a pilot? Or does the conversation simply evaporate? Those responses tell you much more than asking, “Would you pay for this?” Hypothetical willingness is easy.

A real price forces tradeoffs.

The point is not that every prospect must happily accept your first number. Pricing is a hypothesis, and we will treat it that way later.

The diagnostic question here is broader. Why does demonstrated value fail to become commitment? You may discover that the product saves time but not enough time. You may discover that the user loves it but the purchaser does not benefit. You may discover that the problem is important only during a quarterly event, making a monthly subscription feel wrong.

You may discover that buyers need a small project before they can justify an ongoing contract. You may discover that the product creates genuine value but never creates a moment when paying feels like the obvious next action. Each of those observations points toward a different commercial test. What you should not do is retreat to a more comfortable diagnosis. If qualified buyers have used the product, repeatedly obtained the intended outcome, and then declined to pay, more awareness is not the first problem to solve.

Nor should you pretend the evaluation never happened because the result was inconvenient. The commercial path made it farther than that. That is good news. You have narrowed the problem substantially. Now you are investigating the space between value and commitment.

Stay there until you understand it well enough to form a better hypothesis about price, urgency, buyer, budget, offer, or purchase moment. And when somebody finally crosses that line and pays, resist the temptation to declare victory too early. A payment proves that at least one buyer was willing to make the exchange. A business has one more test waiting.

Will they keep making it?

Pays but Does Not Stay

The first payment feels different from every signal that came before it. Somebody has finally crossed the line.

They did not merely compliment the idea, join the waitlist, finish onboarding, or tell you what they might pay someday. They took money out of a real budget and gave it to you.

That matters. It is also not the end of the diagnostic. A buyer can pay and still reveal that the business is not working. They may cancel after the first month. They may complete a pilot and decline to continue.

They may buy once and never return. They may renew reluctantly until a contract expires, then disappear. They may keep the account technically active while usage collapses to almost nothing. Payment is strong commercial evidence because it proves that, under some set of conditions, the buyer judged the exchange worth making. Renewal tests something harder.

Was the value actually realized after the purchase? This is where acquisition success can hide a retention problem. Imagine a product that helps small agencies generate client proposals.

The founder has solved several earlier failures. The buyer is clear. Outreach works. Prospects try the product. They understand the value. The $99 monthly price is accepted.

Twenty agencies subscribe. Three months later, fifteen have canceled. It would be tempting to diagnose the business at the top of the funnel. Maybe we need more leads. Maybe acquisition volume is too low.

Maybe we should run ads. That might increase revenue temporarily. It would also pour more customers into a system that is losing most of them. The problem is no longer getting somebody to pay. You already proved you can do that.

The problem is what happens after payment. That failure can come from several places. Perhaps the product worked during the sales demonstration but was unreliable in everyday use. Perhaps buyers overestimated how frequently they would need it. Perhaps the first successful result required too much effort to reproduce.

Perhaps the team member who championed the purchase left. Perhaps the product saved time but became unnecessary after the initial project. Perhaps customers liked one capability but discovered that their existing software handled the rest of the workflow well enough. Perhaps the buyer paid because the promise sounded valuable and only later learned that the realized benefit was smaller than expected. Those are very different from an acquisition problem.

The commercial system successfully created a purchase. It failed to create enough continuing reason to repeat the purchase. This distinction becomes especially important in subscription software because recurring revenue can create a misleading sense of stability. A credit card remains on file. The dashboard says active subscriber.

Monthly recurring revenue includes the account. Everything looks fine until cancellation. But the customer’s decision may have changed weeks earlier. Usage dropped. The workflow moved somewhere else.

The champion stopped logging in. The product became optional. Cancellation is sometimes merely the final event in a failure that began much earlier. That means retention evidence includes more than renewal itself. Does the customer repeatedly reach the outcome they paid for?

Does the product become part of a real workflow? Does usage continue because the underlying need continues? Does another person at the company begin relying on it? When something breaks, does the customer complain because they need it fixed, or quietly disappear because they never needed it very much? Those behaviors help distinguish a durable customer from a subscription that has not canceled yet.

This is also where founders can confuse satisfaction with dependence. A customer can be perfectly satisfied and still leave. They may honestly tell you the product is good. They may recommend it. They may have received exactly what they expected.

But if the problem was temporary, infrequent, or solved permanently after one use, a recurring business model may not fit the value being delivered. The product did not necessarily fail. The revenue model might have. That is a useful diagnosis. If customers receive enormous value during a two-week project and then have no reason to return for six months, trying to increase monthly engagement with notifications and gamification is probably solving the wrong problem.

Perhaps the natural commercial unit is a project, transaction, report, season, or event. Retention is not about forcing customers to use software forever. It is about understanding whether the way you charge matches the way value continues. There is another uncomfortable possibility. Sometimes customers leave because the acquisition system was too good.

The promise was stronger than the product. The sales conversation created urgency the experience could not sustain. A discounted annual plan pulled forward a purchase from someone who was never a strong fit. Aggressive onboarding got the customer activated, but the underlying problem was too weak. In those cases, better conversion can actually make retention worse by admitting more marginal buyers.

That is why each failure state has to be interpreted in sequence. A purchase tells you something real. A renewal tells you more. If customers pay and stay, repeatedly experience the intended outcome, and continue judging the exchange worthwhile, you are no longer looking at a hypothetical business. You have evidence of something much more interesting.

But if they pay and leave, do not retreat to the comfortable claim that you simply need more customers. Find out why the exchange stopped making sense. Later, we will go much deeper into what retention teaches you about realized value and whether a customer base can support an actual business.

For now, the diagnostic rule is enough:

Find the furthest point buyers reliably reach, then investigate the break immediately after it. Do not prescribe a problem from the symptom at the end. Diagnose the path that produced it.

Treatment Should Follow Diagnosis

Earlier in this chapter, I mentioned an application that had received several hundred visitors without producing a single paid conversion. The obvious response was more traffic.

The founder wanted to advertise, and the reasoning was not foolish. A few hundred visitors is a small sample. More visitors would produce more data. If the product was good and the problem was simply that too few people had seen it, advertising might be exactly what the business needed.

But before buying more traffic, we looked more closely at the traffic already there. Not everyone was bouncing immediately.

A reasonable number of visitors clicked into the product. Some began signup. Several completed free onboarding.

That did not prove the product was commercially viable, but it made “not enough traffic” a less satisfying diagnosis. The system was already receiving visitors and moving at least some of them forward. Something was breaking later. So instead of immediately increasing the input, we tried to understand what those visitors believed they were evaluating.

We showed the landing page to five people who closely resembled the intended buyer and asked a simple question:

What do you think this product will do for you? We got five different answers. That was more informative than another thousand anonymous page views would have been.

The page itself was polished. Nothing looked obviously wrong. It used language that would have been completely at home on a modern software landing page.

AI-powered growth. Smarter customer acquisition. Turn insights into revenue. Every phrase sounded important. None of them told a buyer precisely what they were being asked to buy. We had been looking at zero conversions and considering an acquisition treatment for what was increasingly looking like a comprehension and offer problem.

That changed the experiment.

We created three versions of the proposition. Each focused on a more specific buyer problem and a more concrete result. Then we used a small amount of paid traffic to test them.

Advertising was no longer the rescue plan. It was instrumentation. We were buying controlled opportunities to observe what happened when different propositions reached plausible buyers. One version began separating itself from the others.

That did not mean we had discovered the perfect landing page. It did not mean the copy alone had created a business. We continued testing the offer and the path to purchase before increasing spend.

Over roughly ten weeks, qualified visitor-to-paid conversion moved from effectively zero to a little over three percent in our tracking. More important than the percentage was what had changed in our reasoning. We no longer believed that the commercial problem was simply a shortage of visitors. We had identified a break, changed something close to that break, and observed different buyer behavior. Only then did increasing traffic begin to make sense. Over the following year, the business eventually crossed $20,000 in monthly recurring revenue.

I would not draw a straight causal line from five conversations and a landing-page rewrite to that result. A business changes in too many ways over a year for that story to be credible.

The useful lesson is narrower. We nearly scaled the input before understanding the failure. Diagnosis changed what we tested. That is the point of the Commercial Failure Diagnostic. When revenue is weak, locate the furthest point in the commercial path that buyers have reliably reached.

Then look immediately after it. If you cannot identify plausible buyers, you have not earned the right to diagnose the outreach. If plausible buyers receive your message but do not respond, you have not earned the right to diagnose onboarding. If they respond but will not evaluate, you do not yet know whether the product creates value in real use. If they try it and do not value the outcome, pricing is probably not your first question.

If they value it but refuse to pay, more traffic does not explain the break. If they pay and then leave, acquisition is no longer the whole problem.

The discipline is simple:

cannot find buyer → no reply → will not try → tries but does not value → values but will not pay → pays but does not stay

Find where your evidence stops. Do not guess beyond it. That last instruction matters because founders regularly promote assumptions into facts without noticing. Suppose you have sent thirty messages to people you believe are appropriate buyers and received no replies. You may believe they would love the product if they tried it.

Maybe they would. The diagnostic does not allow you to record “will not try.” Nobody has reached that decision yet. Your observed failure is no reply. Or suppose ten people have completed a free trial and three are still using the product every week, but you have never presented any of them with a real price.

You may believe they will not pay. You do not know. Your evidence has reached value, perhaps strong value, but not a purchase decision. This is why the diagnostic is less comfortable than a typical funnel dashboard. A funnel will happily give you a percentage. The diagnostic asks whether you have actually observed the behavior you are claiming.

For an app that is not making money, I would write down six lines:

Can I identify plausible buyers?

What evidence says yes?

Do those buyers respond when I reach them?

What evidence says yes?

Will they undertake a real evaluation?

What evidence says yes?

Do they experience meaningful value?

What evidence says yes?

Will they pay under real terms?

What evidence says yes?

After paying, do they continue to judge the exchange worthwhile?

What evidence says yes? Stop at the first answer you cannot support. That is the current commercial frontier. The next useful experiment should usually live near that frontier. Not three steps later because that work is more interesting.

Not three steps earlier because familiar activity feels productive. Near the break. If the problem is no reply, test buyer relevance, access, message, and credibility. If the problem is evaluation, investigate what makes trying the product too costly or unconvincing. If users try but do not value it, study the outcome and the conditions under which it matters.

If value exists but payment does not, investigate economic significance, urgency, buyer authority, offer, price, and the purchase moment. If customers pay but leave, investigate realized value and the continuing reason to buy. None of these diagnoses tells you the answer automatically. That is not what a diagnostic is for. It tells you where to look.

There is a tendency in startup advice to prescribe actions before the problem has been located. Post more. Run ads. Raise your prices. Lower your prices.

Talk to users. Add a free trial. Remove the free trial. Build in public. Do outbound.

Improve onboarding. All of those tactics can work. All of them can also be irrelevant. The commercial job is not to collect more tactics. It is to choose the next test based on the behavior you have actually observed.

That sounds less exciting than growth hacking. It is also much harder to fool yourself with. By the time you can say precisely where buyers stop, “nobody is buying” has become a much more useful statement. Maybe you cannot find anyone who has the problem strongly enough. Maybe you can find them but cannot reach them.

Maybe they will talk but will not try. Maybe they try and shrug. Maybe they care and still keep their wallet closed. Maybe they pay once and decide not to do it again. Each answer changes the work.

And the first answer leads us directly into the next part of the book. Before we improve the offer, pricing, purchase moment, or distribution system, we need to examine the person on the other side of the transaction. Not the generic user. Not the persona we invented because a template asked for one. The person whose circumstances might make payment rational.

The next question is not simply who uses the app. It is who may actually pay.