Part II: Who May Actually Pay?

Chapter 6

Persona Is Not Demand

The Fictional Certainty of a Persona

Somewhere in the world is a 42-year-old vice president named Sarah.

Sarah works at a 250-person professional services company. She manages a team of twelve. Her company makes between $25 million and $50 million a year. She uses Microsoft 365, Salesforce, Slack, and several other products that appeared on the persona template. She values efficiency, innovation, and work-life balance. She is frustrated by manual processes, disconnected systems, and poor visibility. She reads industry newsletters, attends a couple of conferences each year, and is described as comfortable adopting new technology.

If the persona exercise was particularly thorough, we may also know that Sarah prefers podcasts to white papers, researches new software on LinkedIn, worries that her company is falling behind competitors, and likes concise communication from vendors. We can know an impressive amount about Sarah. There is only one problem.

Sarah does not exist.

She is a composite. A buyer persona. An ideal customer profile given enough detail that everyone on the team can picture roughly the same person when somebody says, “our customer.”

There is nothing inherently wrong with this. In fact, some version of it is usually better than the alternative. “Our app is for businesses that want to save time” is not a useful description of a market. It includes approximately every functioning organization on Earth, plus several that are not functioning particularly well but remain interested in saving time.

Specificity helps.

If I am building software for accounting firms, knowing how accounting firms work matters. If I am selling to operations leaders, I should understand what those roles tend to own, what systems they use, what kinds of decisions they make, and what constraints surround them. A persona can help a team choose better examples, write more recognizable language, prioritize integrations, identify possible channels, and stop designing every screen for a vague creature called “the business user.”

The trouble begins when specificity starts feeling like evidence. The more detailed the persona becomes, the easier it is to forget where the details came from.

We chose Sarah’s title. We chose the company size. We chose her frustrations. We decided she values efficiency. We decided she worries about visibility. We decided she is open to new technology. Perhaps some of those decisions came from interviews or market research. Perhaps others came from industry assumptions, prior experience, a template, or somebody in a meeting saying, “Yeah, that sounds about right.”

Then we organize all of it into a professional-looking document. The document has headings. It has categories. It may have charts. It may even have a photograph of a competent-looking executive gazing thoughtfully at a laptop near a window. And because the information is now organized, it begins to feel discovered.

That is the dangerous part.

Technical people are especially susceptible to this because we like structured models. Give us a messy human situation and we will eventually find a reason to create fields for it.

Industry. Company size. Revenue. Role. Seniority.

Geography. Technology stack. Goals. Pain points. Buying triggers.

Preferred channels. Objections. Soon the prospective customer has become a remarkably well-documented person who has never purchased anything from us.

The structure is useful. The implied certainty is not.

A persona can tell you who you intend to sell to. It can tell you what you currently believe about that person. It can help you decide where to begin looking. It cannot tell you whether that person will buy. That distinction matters much more after the product encounters the market.

Suppose you decide your application is for vice presidents of operations at mid-sized professional services firms. The logic looks good. These people manage teams. Your application improves a workflow their teams perform. They have organizational authority. The companies are large enough to afford software. The title is easy to find in a prospecting database.

So you build a list. You rewrite the landing page around operations leadership. You adjust the examples in the product. You send two hundred carefully targeted messages. Almost nobody responds.

What did you learn? This is where a persona can quietly stop acting like a hypothesis and start acting like something that needs to be defended. Maybe the subject line was wrong. Maybe the message was too long. Maybe email is the wrong channel.

Maybe the call to action required too much commitment. Maybe your company lacks credibility. Maybe the landing page needs more proof. Maybe you reached people during a terrible week. All of those explanations are possible.

Another explanation must remain possible too. Maybe vice presidents of operations at those firms are not the people who care most about the problem.

Maybe they oversee the function but rarely feel the consequence themselves. Maybe someone two levels below them spends six hours every Friday dealing with the issue while the vice president receives a summarized report and barely notices. Maybe the problem is common but financially trivial. Maybe another department owns the budget. Maybe the current workaround is annoying but perfectly acceptable. Maybe everyone agrees that the problem exists and nobody considers fixing it important.

The persona does not get to rule those possibilities out. That is the discipline I want to establish at the beginning of this part of the book. A useful buyer definition has to be capable of being wrong.

If every market response can be explained without revisiting the original customer assumption, then the persona is no longer helping you investigate the market. It is helping you protect a theory from the market.

I understand why that happens.

By the time an application launches, the imagined customer may be embedded throughout the product. The website speaks to them. The sales copy names their problems. The roadmap includes features supposedly important to them. The onboarding flow assumes something about how they work. The CRM is full of contacts whose job titles resemble the original profile.

There may be a surprising amount of real infrastructure surrounding a customer assumption that has never been seriously tested. That can make changing the buyer feel expensive, both technically and psychologically. If the persona is wrong, what else did we get wrong? Maybe some things. That is not a reason to preserve them.

More often, the original decisions were perfectly reasonable decisions made with the evidence available at the time. The mistake is not beginning with a hypothesis. You have to begin somewhere.

The mistake is refusing to update the hypothesis after better evidence arrives. I would much rather work with a founder who says, “We thought this was for CTOs, but the conversations keep pulling us toward operations managers,” than one who insists the market must eventually conform to an ICP because the team spent three workshops developing it. An assumption does not become stronger because it survived PowerPoint.

The same problem appears with increasingly sophisticated market research. We can estimate market size, identify industries, analyze job titles, scrape technology stacks, study competitors, build prospect databases, and ask AI systems to generate persona documents detailed enough to include hobbies.

None of that is worthless. It simply answers a different kind of question. It helps us describe and locate possible buyers. Demand begins when those people encounter a real problem, under real conditions, and behave in ways that make purchase plausible. That is a higher standard.

So I do not want you to throw away your personas. I want you to demote them.

Treat a persona as an organized guess about where useful evidence might be found. Let it guide your first search. Let it improve your language. Let it give the team a common starting point.

Then make it answer to actual people. Because the commercial question is not whether you can describe your ideal customer convincingly. It is whether something about a real customer’s situation gives that person a reason to buy.

Buying Conditions

Once I stop treating a persona as proof of demand, I still need something better than “go talk to customers.” That advice is directionally correct and operationally vague. Which customers? More importantly, what am I looking for when I find them? The answer I have come to prefer is to separate descriptive attributes from buying conditions.

Descriptive attributes tell me where somebody sits in the world. Industry. Role. Company size. Geography. Technology environment. Seniority. Those things can help me locate a plausible population.

Buying conditions tell me why someone inside that population might make a commercial decision. That is a different kind of information. When I look at a possible buyer now, I want to know whether several conditions are present. Does this person actually encounter the problem the product addresses? What happens when the problem continues?

Do they own some part of that consequence? Can they influence or authorize a purchase? Is there a reason the problem matters now rather than eventually? Can they realistically afford the kind of solution I am offering? Can I reach them through a credible path?

And if I reach them, is there a plausible reason they would trust me enough to evaluate what I am selling? That is much closer to a buying-context profile than a traditional persona. Consider the difference. “VP of Operations at a 100-to-500-person professional services firm” describes a person I can search for. “Responsible for a recurring workflow that is missing deadlines, controls the team performing it, has been asked to improve throughput this quarter, and can approve a modest software purchase” describes a situation I can investigate.

The first helps me find LinkedIn profiles. The second gives me reasons to care about particular ones.

This does not mean every buying condition has to be perfectly known before you speak with someone. Quite the opposite. Early-stage founders usually know less than they think, and demanding complete certainty before starting conversations would just turn market research into another form of hiding.

The purpose is to know what you are trying to learn. Suppose you have built an application that automatically assembles recurring client reports.

Your persona says:

Operations managers at agencies with 20 to 100 employees.

Fine. That is a reasonable place to begin. Now imagine three people who fit the description.

The first manages an agency where reports are produced once a month by an administrative employee. The process is slightly annoying but dependable. It takes two hours. Nobody is under pressure to change it.

The second manages an agency where five account managers each build reports manually for their own clients. Formatting is inconsistent. Work gets done late. Senior people spend time correcting it. Clients occasionally complain.

The third manages an agency with almost the same workflow as the second, but the company recently built an internal reporting tool and has no interest in replacing it. Same persona. Three very different commercial situations. That is why I want the conditions. The conditions keep us from assuming that membership in a category creates equal demand.

The problem condition asks whether the issue actually exists in this buyer’s environment. Not whether people in this industry commonly experience it. Not whether a research report says the category struggles with it. Does this person deal with it?

The consequence condition asks what changes because the problem exists. We do not need to calculate a perfect return on investment yet. Chapter 7 will spend much more time on economic significance. At this stage, I simply want to know whether the problem reaches beyond mild inconvenience.

Does somebody lose time? Does work get delayed? Does quality suffer? Does the problem create rework, risk, missed revenue, frustration from customers, or pressure from management? If nothing meaningful happens when the problem continues, I become less interested.

The authority condition asks whether the person can affect what happens next. This is not always the same as asking whether they can sign the contract. A person may not control the final budget but may have enough influence to initiate an evaluation, bring in a manager, secure internal support, or become the person pushing the purchase forward. Another person may have impressive organizational authority and almost no interest in your particular problem. The CTO story from the previous section is exactly why I separate those ideas.

Authority matters. Relevance matters too. Then there is timing. This is one of the easiest things to leave out of a persona because timing makes the customer inconveniently temporary. A persona wants Sarah to be Sarah all year.

Real buyers change. The same operations director may ignore you in March and urgently call you in September because something happened. A contract is ending. A customer complained. The team grew.

The team shrank. A deadline appeared. A manager demanded improvement. A new regulation arrived. The current tool became intolerable. A problem that has existed for three years can become worth solving on Tuesday.

That does not mean every product needs some manufactured urgency timer counting down beside the checkout button. It means willingness to act often depends on circumstances that are not permanent personality traits.

“Values efficiency” is not timing. “My team has to reduce this process from three days to one before next quarter” is timing. The ability-to-pay condition is similarly basic and frequently ignored. A buyer can have the problem, understand the value, and want the product while still being commercially wrong for the offer you have designed. Someone who could rationally pay $20 a month is not necessarily a buyer for a $20,000 implementation.

A large company may have plenty of money in the abstract while the specific team has no budget. A founder may have an expensive problem and no cash. A department may have budget available only during a particular planning cycle.

Again, I am not trying to solve pricing here. We will give price its own treatment later because it deserves one.

For buyer selection, I simply want to avoid building a market hypothesis around people who cannot plausibly participate in the economic exchange I need. Then come reachability and trust. These need to appear in the buyer definition even though we will examine them much more seriously later. A theoretically wonderful buyer whom you cannot identify, reach, or credibly engage may be a difficult place to learn. Likewise, a buyer may have the problem, authority, urgency, and budget but require a level of proof, reputation, security assurance, or organizational credibility you cannot yet provide.

That does not make them a bad market forever. It changes their usefulness as a buyer you can test right now. This is one reason I resist profiles that contain dozens of demographic and psychographic fields while leaving out whether the founder has any realistic path to a conversation. We know Sarah listens to podcasts. Excellent.

Can we talk to Sarah? That may be worth putting slightly higher on the worksheet. None of these conditions proves demand. That distinction is important enough to repeat because it would be easy to create a new form of false certainty here. A person can have the problem, feel a consequence, hold authority, possess budget, face a deadline, be reachable, and still decline your product.

They may prefer an alternative. They may dislike the implementation. They may not trust the result. The price may still be wrong. The problem may matter, but not enough.

Buying conditions make purchase plausible. They do not make it inevitable. That is the standard we need at this point in the book.

We are not trying to predict buyers with perfect accuracy from a spreadsheet. We are trying to improve the quality of the people from whom we collect commercial evidence.

A useful exercise is to take your current ICP and rewrite it without personality adjectives.

Remove:

innovative.

efficiency-minded.

growth-oriented.

tech-savvy.

forward-thinking.

Unless those words point to something you can actually observe, they are mostly decoration. Replace them with conditions.

Instead of:

Operations leaders at growing companies who value automation.

Try:

Operations leaders responsible for a recurring manual workflow, where delays or rework are visible to management, who can influence a software purchase and are currently under pressure to improve the process.

That description is less charming. It is also much more useful. You can investigate whether those people exist. You can ask what the workflow looks like. You can discover whether they actually own it.

You can learn how decisions get made. You can find out what changed recently. You can discover that the entire theory is wrong. That last capability is not a defect. It is what makes the buyer definition commercially useful.

A persona tells you who you imagine standing on the other side of the transaction. Buying conditions tell you what would have to be true about that person’s situation for the transaction to make sense. And once you start looking at the situation instead of the profile, another complication becomes impossible to ignore. The person experiencing the problem may not be the person making the purchase at all.

User, Champion, Buyer, Payer

The buyer question gets more complicated when the person using the application is not the person deciding whether money changes hands.

We already separated users from customers in Chapter 3. That distinction was about evidence. Someone can use a product, like it, return to it, and still provide no evidence that the business model works.

In B2B software, there is another layer. Several people can participate in the same purchase while caring about completely different things. The user interacts with the product. The champion wants the product adopted and is willing to advocate for it. The buyer has meaningful authority over whether the purchase proceeds. The payer is the person, department, or organization whose budget ultimately funds it.

Sometimes all four roles belong to the same person. If you sell a $29 application directly to an independent consultant, the person discovering the product may use it, decide whether it is worth buying, enter the credit card, and personally feel the small sting when the charge appears.

That is wonderfully simple. Enjoy it while you can. As the purchase becomes larger or the organization becomes more complex, the roles often separate. Imagine an application that helps field technicians produce more accurate service reports.

The technicians use it. They care whether it is fast, whether it works on the devices they carry, whether it makes entering information easier, and whether it saves them from doing the same work again later.

Their manager may become the champion. The manager sees something different. Reports arrive sooner. Fewer need to be corrected. The team spends less time chasing missing information. The manager may care about the user experience, but mostly because the user experience affects the operation.

An operations director may control the budget. Now the conversation changes again. The director may care about throughput, labor, customer complaints, consistency, and whether the application can produce enough improvement to justify adding another vendor and another expense.

Depending on the organization, somebody else may still have the ability to stop the transaction. IT may need to approve an integration. Security may have questions. Procurement may have a process. Finance may actually issue the payment.

That does not mean every B2B purchase requires a wall-sized diagram covered with arrows and job titles. A small purchase may involve two people. A large enterprise purchase can involve enough participants to make a family reunion look administratively efficient.

The point is simpler. If different people participate in the decision, interviewing one of them does not necessarily tell you what the others need. This is especially dangerous when you talk only to users.

Users can teach you an enormous amount about the product. They know where the workflow is awkward. They know which steps take too long. They know what information is missing. They know which feature would save them three clicks because they perform the task twenty times a day.

That information matters. But a user may have no idea how the purchase is approved. They may not know which budget pays for software. They may not know what their manager needs to justify the expense. They may not know that another department has already purchased something similar.

They may not know whether $50 a month is trivial or impossible under the organization’s rules. A user can be completely sincere when saying, “We need this,” while being several organizational steps removed from anyone capable of buying it. The reverse problem is just as common. Founders are frequently told to “reach the decision-maker,” which sounds sensible until you imagine the CEO of a 5,000-person company spending the morning personally evaluating your document-formatting application. The CEO can probably authorize the purchase.

That does not make the CEO the best person to begin with. Authority without relevance can be almost as useless as relevance without authority.

That was part of what made the CTO example in the previous section useful. We had identified someone with substantial authority over technology. What we had not established was that the particular problem mattered enough to that person.

The operations leader was closer to the consequence. That does not automatically make the operations leader the payer either. This is where the word customer can become too blurry to be useful. Suppose five technicians use the application every day. Their manager strongly supports adoption.

The operations director agrees that the product solves a real problem. Finance controls the budget. Who is the customer? For some purposes, all of them. For a commercial diagnosis, that answer is not precise enough.

I want to know who feels the problem, who benefits from solving it, who wants the change, who has authority, who can block it, and whose money is actually involved. Those answers tell me where the purchase can break. If the users love the application but nobody will advocate for it internally, I have one problem. If the champion wants it but cannot get budget approval, I have another. If the budget owner sees the value but the users refuse to change their workflow, that is another problem again.

The product can be identical in all three situations. What changes is the structure surrounding the decision. This is also why positive feedback needs context. “I love this” from the person who uses the product every day is excellent product evidence. “I need this for my team” from a manager is different.

“I can approve this at the proposed amount” is different again. None should be inflated into evidence it does not contain. The technician’s enthusiasm does not automatically represent the budget owner. The executive’s authority does not automatically represent the technician’s willingness to adopt. The champion’s persistence does not guarantee that finance agrees. You need to know whose evidence you are looking at.

For an early-stage app, I would keep the exercise simple. Take one plausible purchase and write down the people involved.

Who uses it? Who most wants the problem solved? Who would push for adoption if the product worked? Who has enough authority to move the purchase forward? Who can stop it? Where does the money come from?

If the same name appears beside every question, great. You have a relatively simple buying structure.

If five different names appear, that is not bad news. It is information. The mistake is pretending those five people are one fictional customer because the persona template only gave you space for one photograph.

Once you see the roles separately, buyer research becomes much more useful. You stop asking only, “What does our customer want?”

You start asking which person wants what, who can stop the purchase, and who has to carry the decision forward. Once those roles are separate, the buying structure itself becomes part of the commercial problem.

Buying Structure Changes the Motion

The same product can require very different commercial work depending on how user, champion, buyer, and payer are arranged. The roles matter, but so does the distance between them.

When one person uses the product, understands the consequence, can approve the expense, and pays, the sale is mostly a decision problem. The founder has to make the value and the tradeoff clear enough for one person to say yes or no. That is the simplest structure, although simple does not mean easy.

When the user and payer are different, the sale becomes partly a coaching problem. An enthusiastic user may become a champion, but enthusiasm is not authority. The champion has to carry the case internally. They need a concise explanation of the consequence, the expected result, the cost, the implementation burden, and the reason the change is worth spending political capital on. If they cannot explain the purchase without you in the room, the buying path is fragile.

When several people can approve, block, or materially reshape the purchase, the problem becomes coordination. Finance may care about the economic case. Security may care about access and data. Operations may care about disruption. The manager may care about accountability if the promised result does not arrive. A founder who keeps selling the same feature story to every participant is not simplifying the sale. They are forcing each participant to translate it into a different risk model.

A department-wide purchase creates another problem after approval: internal adoption. The external sale can be won while the internal rollout fails. In that situation, training, workflow ownership, internal proof, and a credible first use case are part of the commercial motion because the buyer is purchasing a change that other people have to accept.

None of these structures is inherently superior. They simply demand different work. Do not label every B2B sale enterprise and assume the same playbook applies. Put actual names beside the roles, identify who can say no, and ask what the next person in the chain needs to believe. The buying motion should follow the buying structure, not the org chart you wish existed. But even a perfectly mapped buying structure does not matter if the problem itself is too weak to fund. The next question is what kind of problem creates enough consequence for any of these people to act.