Chapter 20

Your First Customer Path

I Told Him to Stop

One of the more memorable founders I have coached came to me convinced he had a marketing problem. He had spent nearly a year building an AI application for small agencies. It was technically substantial and, by any reasonable standard, polished. It already integrated with several of the tools agencies use. He had a website, a newsletter, outbound sequences running, and a growing list of features he intended to add. He had no paying customers, and his plan was to fix that by increasing outreach from a few hundred messages a month to several thousand.

I told him to stop. Not forever. For two weeks.

I want to be honest about how that suggestion landed, because it is the same way it would have landed on me a few years earlier. To a builder who has spent a year producing something real, “stop marketing” sounds like advice to do less of the one activity that might produce a customer. It sounds passive. It sounds, frankly, like the sort of thing a consultant says to justify a second meeting. His objection was reasonable: the product was ready, the market was large, and the only variable he could see left to change was volume.

What I saw was different, and it was not a marketing problem. It was that the phrase “get your first customer” was hiding a sequence of separate decisions, and none of them had been made. “Agency owners” was an enormous category with no evidence about which agencies had an expensive problem. The messaging emphasized AI automation, which is a description of the product rather than a reason to buy it. The free trial invited people to explore, which meant no purchase moment existed anywhere in the funnel. There was no specific problem with a cost attached, no bounded offer, no tested price, and no visible reason for any agency owner to act this month rather than next year. Sending several thousand messages into that structure would not have produced a first customer. It would have produced several thousand data points about a proposition that had not been specified well enough to be accepted or rejected.

That is the pattern this chapter is about. Founders talk about the first customer as if it were an event, a threshold you cross when enough effort has been applied. In my experience it is closer to a chain of decisions, each of which can be made carefully or by default, and most of which the founder has already made by default without noticing. Who is the buyer? Whoever fits the category. What is the paid problem? Whatever the product does. What is the offer? Access to the software. What is the price? Whatever the pricing page says. What commitment are we asking for? A trial. What would a skeptical buyer object to? We will find out. How does the conversation happen? Outreach. What decision are we asking them to make? None, really, yet.

Every link in that chain was weak in his case, and the weakness was invisible from inside the activity, because activity was the thing being measured. He knew his open rates. He did not know which agencies paid someone to do the work his product automated, because he had never asked.

The previous nineteen chapters have taken those links apart one at a time. This chapter puts them back together in the order they have to run for a real person to buy something. I call the result the First Customer Path, which is a modest name for a modest thing: a sequence you can walk a real buyer through, with a check at each step for whether you have evidence or an assumption. It is not a diagram I invented for the book. It is the order I actually use when a founder tells me nobody is buying, and it is what the two weeks were for.

What the founder did with those two weeks is the rest of this chapter. He did not build a major feature. He did not write new sequences. He interviewed twelve agency owners instead of contacting another twelve thousand, and by the end of it the business had a first customer, a second, and a much narrower idea of what it was selling and to whom. The sequence mattered more than the effort.

Before walking through it, the sequence needs to be stated plainly, along with the reason it runs in this order and not another.

Buyer and Paid Problem

So instead of contacting another twelve thousand people, we interviewed twelve agency owners.

The number was not scientific. Twelve was roughly the number of reachable people who fit the category and would agree to thirty minutes in a two-week window, and I would rather be honest about that than dress it up as a methodology. The interviews were also not customer-discovery theater. The founder did not ask whether people liked the idea, whether they would use the product, or which features they would want. He had been asking those questions for a year, in one form or another, and they had produced a year of encouragement. The questions this time were the ones the Paid Problem Test is built from. What do you do today that this product might replace? Who does it? How long does it take? What does it cost you when it is late or wrong? What have you already tried?

Most of the twelve were mildly interested, which is what you would expect and what the earlier outreach had already established. Mild interest is the resting state of a reasonable person shown a competent product. It is not nothing. It is also not a buyer.

Three of them described the same problem, and they described it in almost the same economic terms. Recurring client reports were consuming senior employee time every month. Clients expected the reports as part of the existing retainer, so the agency could not easily charge more for producing them. The agency also did not want experienced staff spending hours each month assembling something that was, from the client’s point of view, a deliverable that should simply appear. The problem was not “reporting is tedious.” Tedious problems are everywhere and rarely paid for. The problem was that a fixed-fee retainer was quietly absorbing hours of expensive labor every month with no way to recover the cost, and the people running those agencies could tell you roughly what it was costing them without looking anything up.

That was different from the other nine, and the difference was the whole point of the exercise. “Agency owners” had been the buyer. After twelve conversations, the buyer was an agency owner whose retainer clients expected recurring reports that senior staff were assembling by hand. That is a much smaller category. It is also a category with an observable workaround, a cost the owner is already aware of, and a reason the owner might act, which is that the labor recurs every month whether or not anyone decides to fix it.

I want to draw out two things from this, because the story can be misread as “do customer interviews,” which is advice the founder had already received and followed for a year.

The first is that the interviews worked because they asked about behavior and cost rather than opinion and desire. Nine of twelve people had opinions. Three of twelve had a workaround they could describe in detail and a cost they were already paying. The product had not changed between the two groups. The questions had. If you interview twelve people and come away with twelve opinions about your product, the interviews were probably structured to produce opinions.

The second is that the buyer became specific as a result of the problem, not the other way around. The founder did not decide to target agencies with heavy reporting obligations and then go looking for them. He talked to a broad group, listened for the problem that showed up with a cost attached, and then let that problem define who the buyer was. This is the order the persona chapter argued for, and it is the order most founders reverse. Starting from a persona and searching for a problem to justify it tends to produce a problem that fits the product. Starting from observed cost and letting it name the buyer tends to produce a buyer who can pay.

There is a boundary to draw here too. Three out of twelve is not a market. It is three conversations that produced consistent evidence of a paid problem, which is enough to build a bounded offer around and enough to justify the next test, and not one thing more. The founder was, at this point, still a person with no customers. What he had that he did not have two weeks earlier was a specific buyer, a specific problem, and a number to attach to the problem. The next question was what, exactly, to offer them.

Smallest Offer, Price, and Commitment

The founder’s instinct at this point was the one every builder in this book has had, and I include myself. Three agencies had described a reporting problem. The product handled reporting as one of many capabilities. Surely the next move was to build a proper reporting module, with templates and scheduling and a client portal, so that the offer would be complete.

He did not build a major new feature, and the fact that he did not is one of the more useful parts of the story.

What he did instead was configure what already existed around that one workflow. The application could already pull the data, already integrated with the tools the agencies used, and could already produce output in roughly the shape a client report needed. What it lacked was not capability. It was a proposition narrow enough that an agency owner could evaluate it against the specific monthly cost they had just described. So the offer became this: give us your current reporting process, and within a week you will have an automated version built around it. Not a platform. Not “AI for agencies.” One recurring deliverable, produced automatically, for the clients you already have, in the format they already expect.

That is the smallest thing worth paying for, in the sense the earlier chapter meant. It was small in scope, one workflow instead of everything the product could do. It was not small in value, because the workflow it removed was the one the buyer had already priced. And it was bounded in a way that made evaluation possible. The owner could look at last month’s report, look at the automated one, and decide whether the difference in senior staff hours was worth the price. There was nothing to imagine.

The price came next, and it was structured to match how the buyer experienced the problem. The first agency paid $2,000 for implementation plus $500 per month. The implementation fee covered the work of mapping their process into the system, which was real work and which also served a commercial purpose the pricing chapter would recognize: it asked for a meaningful commitment up front, from a buyer who had a meaningful cost to compare it against. The monthly fee was modest relative to the labor it replaced. Neither number was derived from a spreadsheet of competitor prices. Both were hypotheses, set at a level where a yes would be informative and a no would be worth understanding.

Here the path did something the previous year of activity had never done. It created a purchase moment. The free trial had invited exploration, and exploration does not end in a decision. The setup offer required one. An agency owner either handed over their reporting process and paid for the implementation, or they did not, and either way the founder learned something a trial signup could not tell him. The first agency said yes. The second paid a similar amount. Two purchases are two purchases, not a business, and I want to be careful to say so. But they were the first two times in a year that a buyer had been given a specific proposition and accepted it, and that changed what every subsequent conversation could be about.

It is worth pausing on what was not tested. Nobody ran a pricing survey. Nobody asked the twelve interviewees what they would pay. The offer and price were put in front of buyers who had already described the cost, and the buyers’ behavior did the testing. That is the entire argument of Part III compressed into one decision, and I would rather it be visible here than stated again as a principle.

There was one more step before the conversation, and it is the one founders most often skip when the offer finally feels right. The founder now had a proposition a buyer could accept. He had not yet made the buyer’s case for refusing it.

The Skeptical-Buyer Check and the Conversation

The Buyer Stress Test from Chapter 16 exists for exactly this moment: the proposition is specific enough to be attacked, and nobody has attacked it yet.

I do not want to re-run that chapter here. The point of applying it inside the path is narrower. Before the founder spends his scarce hours in conversations with the three agencies that described the problem, and before he spends any effort finding more like them, the proposition should survive the strongest honest case a rational agency owner could make for saying no. Not the objections the founder hopes to hear. The ones he would make himself if he owned the agency.

For the reporting offer, those were not hard to find. The owner is being asked to hand a client-facing deliverable to a one-person software company. If the automated report is wrong, the client sees it, not the founder. The agency’s reports contain client data, and the founder has no security page, no references in this segment, and no track record the owner can check. The $2,000 implementation fee is a real decision for a small agency and requires the owner to believe the one-week promise, from someone who has never delivered it to anyone. The senior employee who currently builds the reports may have opinions about being automated, and those opinions will arrive after the purchase, not before. And the status quo works. The reports go out. They are expensive, but expensive-and-working is a formidable competitor, as the stress-test chapter argued.

Running that exercise does not usually change the offer much. It changes the conversation. A founder who walks into the call with the objections already on the table does not need the buyer to raise them, and the responses that work are rarely complicated. A sample report built from the buyer’s own data answers “what if it is wrong” with evidence rather than reassurance. A plain explanation of where the data lives and who can see it answers the security question at the level a small agency actually asks it. Offering to review the first automated report with the owner before it reaches any client turns the riskiest moment into a shared one. And saying, honestly, that the one-week promise is new and that the implementation fee is partly a test of whether the proposition is worth that much to the buyer sounds like weakness and reads, to a skeptical owner, like the first candid thing a vendor has said all year.

Then came the conversations themselves, and here the previous chapter did the preparatory work. The three owners who had described the problem were the queue. They had fit, an observable paid problem, authority (they owned the agencies), a recurring trigger (the reports were due again next month), a warm-enough path (they had already given thirty minutes and been asked good questions), and in two cases a demonstrated willingness to be candid about what the reports were costing them. Those were not conversations the founder had to go find. They were the highest-scoring rows in a table he had built by accident while doing the interviews.

The conversation had one job that the year of prior activity had never assigned to any interaction: to ask clearly for a decision. Not “what do you think,” not “would this be useful,” not “let me know when you want to start.” The ask was, in substance: here is the offer, here is the price, here is the date we could start, and here is what I would need from you to begin. Would you like to do this?

That is a different sentence from anything in the old funnel, and it is uncomfortable to say the first time. I understand the discomfort from the inside. A trial invitation cannot be refused, and a founder who has only ever issued trial invitations has never been refused, which is not the same as having been accepted. The purchase-moment chapter made that argument at length. In the path, it is simply the last step before evidence exists.

The first agency said yes. A second paid a similar amount. Not every conversation ends that way, and the ones that do not are worth as much to the record as the ones that do, provided the reason is captured. To make the point with a hypothetical rather than pretending to remember a conversation I did not sit in on: an owner who declines because their largest client is about to change its reporting requirements has given you a timing objection with a named cause. That is not “not interested,” and it is not silence, both of which this founder had a year’s supply of. It is a specific refusal of a specific proposition, and it belongs in the same record as the yeses.

Which is the step founders most reliably skip, because it feels like paperwork after the interesting part is over.

Record the Evidence

Engineers keep logs. We instrument systems, capture what happened, and go back to the record when something behaves unexpectedly, because memory is a poor substitute for a trace. Then most of us run the commercial side of the business entirely from memory, and are surprised when the story we tell about it drifts.

The evidence step of the path is not glamorous. It is the habit of writing down, for each buyer who moves through the sequence, what actually happened at each step: who they were and why they qualified, what workaround and cost they described, which offer they were shown, what price and commitment were asked for, what they said in response, what objections surfaced, what they did afterward, and how they came to be in the conversation in the first place. One row per buyer. Facts, not impressions.

The reason this matters is that human memory of commercial conversations is systematically optimistic. A founder who had a warm forty-minute call remembers it as interest. The record shows the buyer never answered the price question. A founder who received three feature requests remembers demand for the feature. The record shows none of the three would commit to anything if it were built. A founder who got two yeses and one no remembers a strong signal. The record shows both yeses came from agencies with more than ten retainer clients and the no came from one with three, which is a hypothesis about the buyer that would have been lost in the glow.

I want to be precise about what the record is for, because it is easy to turn into a CRM project and then never look at it. It is for three things. It tells you which step of the path each buyer actually reached, so that “we have a pipeline” can be replaced with “four buyers reached the price step, two accepted, one refused on timing, one went quiet.” It preserves the reasons, so that a refusal recorded today can be compared with a refusal recorded next month and a pattern can become visible. And it makes the Payer Delta later in this part possible, because comparing the buyer who paid with the similar buyer who did not is only possible if you wrote down what was similar and what was different while it was still true.

The record does not need software. For a company with two customers, a spreadsheet is exactly the right amount of infrastructure. In the founder’s case it would have been twelve interview rows, each with the workaround and cost described, three of them flagged as having the reporting problem, and for those three the offer shown, the price asked, the response, and the reason. It would have fit on one screen. Later, when I built some of these questions into Make it RAIN, it was because I wanted a repeatable way to force myself to fill in the row rather than trust my recollection of the call, not because a spreadsheet could not do it.

There is a discipline about what goes in the record that is worth stating, because it is where the evidence standard from earlier in the book becomes a daily practice. Write what the buyer did, not what you inferred. “Said the reports take a senior person most of a day each month” is an observation. “Has a strong need” is an interpretation. “Agreed to a paid implementation starting the 14th” is an observation. “Very interested” is the sentence that has misled more founders than any other in this book. The record should be boring to read and impossible to argue with.

Kept that way, the record starts to do something the founder cannot do alone. It answers, without flattery, whether the path is repeating.

If you want to run this path as a time-boxed operating cycle rather than a chapter-by-chapter exercise, Appendix I turns it into a 30-day sequence. The point of the deadline is not to guarantee a customer in thirty days. It is to force enough real buyer decisions that the commercial model is less imaginary at the end of the month than it was at the beginning.

Repeat or Revise

By the sixth customer, the founder had narrowed the product, increased the recurring price, and stopped describing the company as a general AI platform.

I want to draw attention to the order of those three changes, because it is the reverse of the order most founders would have chosen a year earlier. He did not narrow the product in order to find customers. He found customers, saw what they had in common, and then narrowed the product to match what was actually being bought. He did not raise the price because a spreadsheet suggested he was underpriced. He raised it because buyers with a named monthly cost were accepting the offer without much resistance, which is the kind of behavioral evidence the pricing chapter says to look for before touching the number. And he stopped calling the company an AI platform because none of the six had bought an AI platform. They had bought the removal of a recurring reporting cost, and the positioning caught up with the purchase.

That is what the last step of the path means. Every time a buyer moves through the sequence and reaches a decision, the founder faces a choice: run the same path again with the next similar buyer, or revise one of the steps because the decision revealed something. Repeat when the evidence says the path is working as specified. Revise when a yes or a no shows that one of the links was wrong or could be tightened. The founder’s first six customers produced both. The path repeated, in that the buyer definition, the paid problem, and the setup offer stayed recognizably the same. It also revised, in that the price moved, the scope narrowed, and the language changed as the record accumulated.

A year later, the business had more than thirty agency customers and approximately $25,000 in monthly recurring revenue. I report those numbers because they are what happened and because they show the changed direction was commercially meaningful, not because they are the point. Thirty customers acquired over a year through a repeatable sequence is a different kind of fact from thirty customers acquired somehow, and the difference is what Part V is about.

What I find most useful about the story is not the revenue. It is that at the end of the year the founder could answer, in one sentence each, the questions he could not answer at the start. Who buys? Owners of agencies whose retainer clients expect recurring reports that senior staff currently assemble by hand. What expensive problem causes them to act? Unrecoverable monthly labor inside a fixed-fee arrangement. How do they find us? Largely through the paths that produced the first six, which the record could name. What do they pay for? A configured reporting workflow with an implementation fee and a monthly subscription. Why do they stay? Because the reports go out every month and the senior person’s hours do not come back.

He could not answer any of those a year earlier, and he had been working very hard. The difference was not effort or persuasion. It was that the market had finally been given a specific proposition to accept or reject, and it had been allowed to do both.

I should say clearly what this story does not prove, because it is exactly the sort of story that gets stretched. It does not prove that twelve interviews are enough, that agencies are uniquely good buyers, that implementation fees should always accompany software, or that stopping marketing is generally wise. It does not prove that the coaching caused the growth; the founder did the work, and plenty happened in that year that I did not see. It shows one sequence, run honestly, producing a first customer and then a second and then a business, in a situation where a year of undirected promotion had produced none. That is enough to justify the sequence. It is not enough to make it a law.

The path also has an ending that is not really an ending. The first payment is a threshold, and it deserves the small celebration founders usually skip on their way to worrying about the second. But the two most informative events in the whole sequence are the ones the path produces last: a buyer who says no for a reason, and a buyer who says yes for a reason. Once a person refuses, the reason matters, because it may be telling you which step of the path is wrong. Once a person pays, the reason matters even more, because it may be telling you what the business actually is, which is not always what you thought you were building.

Neither reason arrives labeled. They have to be extracted, and extracting them is a different kind of work from everything Part IV has covered. It is less about getting to the buyer and more about listening to what the buyer’s decision was made of.