Chapter 15

Trust Is Its Own Problem

The Invisible Objection

A team I worked with built an AI application for a large enterprise.

The demonstration went extremely well. Executives could see the potential. Technical stakeholders understood what the application was doing and were interested in where it could go. The product addressed a recognizable problem, and the part that looked technically difficult on a screen was working.

Then the project stalled.

At first, nothing about the stall looked like a trust problem. Nobody said, “We don’t trust you.” People continued saying encouraging things about the product. They just started asking different questions.

Security wanted to know what happened to the data. Infrastructure wanted to know where the application would run. Operations wanted to know who owned the problem when something failed. Legal had questions about third-party services. Managers wanted to understand what happened when the model was uncertain or produced a result nobody should act on automatically.

Each question was legitimate on its own. Taken separately, they looked like requirements surrounding the application. Taken together, they were the purchase.

That distinction took me some time to appreciate. From the technical side, we had been thinking about whether the system worked. The organization had moved on to a harder question: What happens to us if we trust this enough to use it? The first evaluation can go beautifully while the second fails completely.

This is why trust can be difficult to diagnose. It rarely arrives labeled TRUST OBJECTION. Buyers ask for another document. They involve security. They delay the implementation conversation. They ask about support, references, continuity, or what happens if the company disappears. Sometimes they simply stop moving.

From the founder’s side, that can look like almost anything. Maybe the pain is not strong enough. Maybe the price is too high. Maybe procurement is slow. Maybe the buyer wants another feature. Maybe the internal champion lost interest. All of those things happen.

But sometimes the buyer has already crossed several thresholds founders spend enormous energy trying to prove. They understand the problem. They believe the product could help. They can see enough economic value to continue the conversation. They may even agree that the proposed price is reasonable. What they cannot yet do is become comfortable with the consequences of being wrong about you.

Earlier in the book, I treated trust as part of the distance between an early founder and a first buyer. That mattered because a theoretically attractive market can be a poor place to learn when you have no credible path into the buying process. Here the problem is narrower. You are already in the room. The buyer is not ignoring you. The product has survived enough scrutiny that serious people are spending time evaluating it.

Then progress slows because liking the product and trusting the purchase turn out to be different decisions.

When founders hear the word trust, we can interpret it personally. Do they think I am dishonest? Does the company look too small? Do I need a more professional website? Should I add testimonials?

Maybe. But commercial trust is broader than whether the buyer thinks you are a decent person. A buyer may find you intelligent, conscientious, responsive, and entirely sincere while still deciding that putting your product into an important workflow creates more risk than they are prepared to own. They are not necessarily judging your character. They are judging the bet.

Suppose you sell a tool that processes important customer information. The buyer may believe every word you say and still want evidence about how the data is handled. If the product becomes part of a recurring operational process, they may genuinely like you and still worry about what happens when something breaks on a Friday afternoon. If the application makes recommendations employees will use, the buyer may believe the model is impressive while remaining uncertain about how mistakes become visible and contained.

In the enterprise project, that was the uncomfortable realization. We had solved the part of the problem that made the demonstration exciting. We had not yet made the decision safe enough for the organization to own.

That changed how I interpreted the questions. Security was not an annoying final obstacle standing between good technology and deployment. Operations was not being negative because it wanted someone named beside a failure condition. The people asking those questions were examining the downside that the demonstration had not needed to carry.

The smaller the consequence of a bad decision, the easier this is to forget. I have installed inexpensive utilities from developers I knew almost nothing about because the downside was limited. If the product disappointed me, I could delete it and continue with my life. That is a very different trust decision from attaching an unknown application to customer data, moving a team onto it, or becoming the person inside a company who said, “I think we should use these people.”

Buyers are not only risking money. They may be risking inconvenience, operational continuity, data, time, political capital, or the possibility of explaining later why they supported a decision that went badly. The scale changes, but the underlying question does not: How much confidence do I need before I let this product become my problem too?

That question is easy to miss because the buyer may never say it. Instead, you hear “We need to think about it,” “Do you have customers like us?”, “What happens if we need support?”, or “I like it. I’m just not ready yet.”

There is a danger in automatically translating those statements into trust. “We need to think about it” can also mean no, not now, not enough value, I do not have authority, or I would like to end this conversation without creating unnecessary emotional debris. Commercial diagnosis would be very easy if every vague sentence had one hidden meaning. It does not.

The useful move is not to ask, “Why don’t you trust us?” Please do not ask that unless you are trying to make an already awkward sales conversation considerably more awkward.

Ask about the decision. What would make proceeding feel risky? What would need to be true for the buyer to become comfortable moving forward? Who else would have concerns if they proposed the purchase internally? If the product worked as demonstrated, what would they still worry about?

Those questions give the buyer room to describe risk without requiring them to pass judgment on you personally. They also produce more useful information than another round of defending the product.

In the enterprise application, the eventual lesson was not that we needed to become more persuasive. We needed to understand what the organization was being asked to trust and make that burden more reasonable. A buyer can say yes to the problem, the product, the value, and perhaps even the economics, then still say no to the risk of choosing you.

When that happens, another feature may not help. Another discount may not help. Another explanation of the ROI may not help. The purchase has reached a different constraint.

Before you can reduce it, you have to see what kind of trust the buyer is actually being asked to extend.

Enterprise Trust Burden

Selling into an enterprise changes the trust problem because one person’s confidence may no longer be sufficient.

Your internal champion can believe in the product, trust you personally, understand the value, and want the purchase to happen. They still may not be allowed to accept all of the risk that comes with it.

That is where enterprise buying becomes confusing for founders. The person you have been working with says yes, but the organization does not move. Another team appears. Then another. Questions arrive about data, access, third parties, outages, legal terms, compliance, and implementation ownership. At some point, a founder can begin to wonder whether anybody remembers what the software actually does.

They do. The organization is now evaluating something larger than the software. It is evaluating the relationship.

Large organizations divide responsibility. The employee who understands your product may not own cybersecurity risk. Security may not be permitted to accept contractual risk. Legal may not own implementation. Procurement may negotiate terms without having any opinion about whether the product is technically good. Operations may have little authority over the contract while having considerable authority over whether the system can safely enter production.

Each group is evaluating a different consequence of saying yes. Enterprise trust is therefore rarely one person’s judgment. It is a chain of permissions.

This resembles the reachability and procurement friction discussed earlier, but it is not the same problem. There, the question was whether a market was reachable enough for an early company to learn from it. Here, assume you have already reached the buyer. You have an interested champion. The value proposition is understood. The application has survived serious evaluation. Now the organization must decide whether it can responsibly adopt what you are selling.

Security is one part of that burden. Depending on the product, the buyer may need to understand authentication, credentials, data transmission and storage, permissions, third-party services, vulnerabilities, and what happens to information when the relationship ends. The requirement should follow the exposure. A browser extension reading public information does not create the same decision as software connected to internal financial systems.

Founders sometimes respond to those questions with reassurance: “We take security very seriously.” I would hope so. The buyer is usually asking for something more inspectable than seriousness. What actually happens to the data? Who can see it? What controls exist? What happens when something goes wrong? Good intentions are not an architecture.

Legal and compliance evaluate other consequences. What has each party promised? What data rights are being granted? What happens if the service fails? How can either party end the agreement? Does adopting the product create obligations the organization must account for? A founder may consider those questions distant from the feature that originally attracted the buyer. They are distant from the feature. They are not distant from the purchase.

Implementation ownership creates another trust burden. A product can be technically installable without being organizationally adoptable. Someone has to configure it, provide data, map the workflow, train users, handle exceptions, decide when the system is ready, and own problems after launch.

If the answer to all of those questions is vaguely “the customer,” you may not have described an implementation plan. You may have described a transfer of uncertainty.

Your champion knows this. They are not merely asking, Do I believe the product could work? They may also be asking, Can I defend this decision to everyone else who will have to live with it?

That changes what useful selling looks like. The goal is not simply to make the champion more enthusiastic. They may already be enthusiastic enough. The goal is to make the decision explainable. What exactly is being deployed? What is not included? What risks remain? Who owns them? What happens first? What can be reversed?

This is where the enterprise AI application from the opening changed.

We did not make the core idea more exciting. We made the proposed relationship easier to reason about. The first release became deliberately narrower. Data boundaries, logging, access controls, human-review points, rollback procedures, and ownership became explicit. We reduced the number of decisions the system could make autonomously and made uncertainty visible rather than hiding it behind a confident interface.

The next executive review looked less futuristic than the first demonstration. It was also the meeting that got the project approved.

The lesson is not that narrower deployments always win, that autonomy is inherently bad, or that every enterprise requires the same controls. The lesson is that the technically most impressive version of a product is not automatically the version an organization can responsibly buy.

When an enterprise asks for another security answer, legal clarification, implementation detail, or operational control, do not automatically translate the request into “they need more features.” Often the organization is not asking the product to become more capable. It is asking the purchase to become more governable.

Those are different engineering problems and different commercial problems.

Not every app needs to cross this burden. Many builders sell something much smaller, simpler, and easier to reverse. Their customers may never see a security questionnaire, legal review, procurement department, or implementation committee.

Trust still matters. It simply shows up in different places.

Borrowed Trust

An unknown company does not always have to manufacture all of its credibility from scratch. Sometimes the buyer encounters the product through something they already trust.

A consultant recommends it. A respected member of a professional community mentions it. The application appears in a marketplace operated by a platform the buyer already uses. A partner introduces the founder. Someone whose judgment the buyer values says, in effect, I have looked at this more closely than you have, and I think it is worth your attention.

Some of that confidence transfers. I think of this as borrowed trust.

The word borrowed matters because the trust does not become yours automatically. A recommendation may get you into the conversation. A marketplace may reduce concern that the product is completely anonymous. A respected partner may make the buyer more willing to evaluate you. You still have to survive the evaluation.

Suppose a business owner receives an email from a software company they have never heard of claiming to save ten hours a week. Maybe it is true, but the owner first has to decide whether the message deserves attention before investigating whether the claim deserves belief.

Now imagine the owner’s accountant says, “I saw a tool that might solve the reporting problem you complained about. I know the person behind it. You should take a look.”

That introduction has not proven that the software works. It has changed the cost of taking the next step. Someone with existing credibility has attached their judgment to the introduction.

Partners can create this effect when buyers already trust them in the relevant domain. The relevance matters. A recommendation about accounting software from an accountant I respect carries more weight than the same recommendation from someone whose expertise is landscape architecture, even if the landscape architect is delightful.

This is why partnerships should not be evaluated only by audience size. A person with a small but highly relevant relationship to the buyer may transmit more trust than a much larger name with no obvious connection to the purchasing decision.

Marketplaces and established platforms can perform a similar function. The buyer may already understand how installation works, recognize the payment system, know what permissions the platform exposes, or expect some baseline rules for participants. The marketplace does not prove the product is good. It makes parts of the transaction less unfamiliar.

Communities work differently. A genuine community has repeated interactions, memory, and reputation. If several people in a community I trust say they have used a product successfully, that information arrives with context and can often be questioned without going through the seller. The seller controls less of the evidence, which can make it more persuasive.

This is also why arriving in a community and performing a highly energetic imitation of participation for three days rarely creates the same effect. Trust accumulated through useful behavior cannot be compressed into a launch announcement.

Borrowed trust has limits, and founders should be precise about what an association proves. Appearing in a marketplace is not an endorsement of every claim you make. Using infrastructure from a well-known technology company does not transfer that company’s entire reputation to your business. A partnership should not be described as approval unless approval is actually what occurred.

The same restraint applies to customer and partner logos. A logo might mean that the company purchased the product, ran a pilot, created a free account, or merely spoke with the founder. Those relationships are not interchangeable. Borrowed trust works because the association is credible. Inflate the association and you damage the thing you were trying to borrow.

Early founders may have more trust available than they realize, even before they have a long operating history. Professional relationships, former colleagues, existing customers, technical communities, specialist advisors, industry groups, and platform marketplaces can all shorten the path when they matter to the buyer.

The useful question is not, Who has a big audience? It is, Who or what does this buyer already rely on to decide what is credible?

That question points toward trust rather than reach. Later, when we discuss distribution, the path through which a buyer encounters the product will matter for attention as well as credibility. For now, the lesson is narrower: you do not always enter the buying decision alone.

Borrowed confidence can move the starting line. It cannot finish the race for you.

Once the buyer evaluates the purchase, they still need enough evidence about you, your product, and the risk they are being asked to accept. That brings us back to the most important diagnostic question in this chapter.

Is trust actually the constraint?

Diagnose Trust Separately

Trust is dangerous as an explanation because it can explain almost anything after the fact.

The buyer did not purchase, so maybe they did not trust us. The trial did not convert, so maybe the website looked questionable. The enterprise evaluation stalled, so maybe we need more references. Those explanations are possible. They are also wonderfully difficult to disprove if you do not separate trust from the other commercial variables around it.

The wrong diagnosis produces the wrong work. A founder who thinks the problem is price offers a discount. A founder who thinks the problem is product adds features. A founder who thinks the problem is messaging rewrites the landing page. A founder who thinks the problem is trust collects testimonials, redesigns the site, creates security documents, adds guarantees, or tries to look more established.

Any of those actions can be sensible. Any of them can be completely irrelevant.

Suppose the buyer worries about how your application handles important business information. Adding three customer testimonials may prove that other people like the product, but it does not tell the buyer where the data goes. If the real concern is company continuity, reducing the monthly fee does not answer what happens if you disappear.

The solution to a trust problem depends on the trust problem. More importantly, the solution to a non-trust problem is not more trust.

Return to the commercial failure states from earlier in the book. A buyer you cannot find is not yet giving you evidence about trust. A buyer who never replies may not know enough about you to distrust you. A buyer who tries the product and finds little value has given you a different problem. A buyer who sees substantial value but rejects the economics may genuinely have a price problem. A buyer who pays and then leaves may have encountered activation, product, support, or retention problems.

Trust can appear at several points in that path. It should not swallow the entire path.

Be especially cautious about diagnosing trust from silence. If someone visits the site and leaves, perhaps the company looked questionable. Perhaps they disliked the price. Perhaps they misunderstood the product. Perhaps they received a Slack message, closed the tab, and never thought about you again.

Silence is still unknown.

Trust becomes a stronger hypothesis when the buyer has already provided evidence about the other parts of the decision. They acknowledge the problem, understand the product, believe it could help, encounter a plausible price, and have a credible path to moving forward. Then the conversation starts circling risk: Who else uses this? What happens if it breaks? Where is our information stored? Can I speak with a customer? Who handles implementation? What happens if your company shuts down?

Now trust deserves serious attention.

None of those questions guarantees a purchase if you answer correctly. Buyers can raise legitimate concerns and still decide the product is not worth buying. The point is not to turn objections into promises. The point is to improve the diagnosis.

One useful test is to mentally remove the trust concern and ask what remains. Suppose the buyer had complete confidence in the company. Would the economics make sense? Suppose they knew the product was reliable. Would they care enough about the problem to change? Suppose security approved the application tomorrow. Is there an actual person prepared to own implementation? Suppose you had ten excellent references. Would the buyer have budget?

Those questions prevent trust from becoming a rescue theory for a weak commercial proposition.

Then run the test in the other direction. Assume the product, value, and price remain exactly as they are. What evidence or reduction in risk would make the buyer more comfortable proceeding?

Specific answers are useful. “We need to understand where our data is retained.” “Our operations lead needs to know who owns failures.” “We need a reference from a customer using this in a similar environment.” Those statements identify uncertainty that can be investigated.

“I just don’t feel comfortable yet” is weaker evidence. Keep investigating. A vague feeling is not a specification.

This distinction protects founders from endless trust theater. There is always another testimonial, certification, founder bio, policy, case study, logo, or page about how deeply the company cares. At some point those additions stop reducing uncertainty and start decorating it.

Commercial learning requires knowing when to stop.

Price should stay separate too. Earlier we saw that higher prices can expose trust problems because larger commitments require more confidence. Once the buyer’s concern is specific, address that concern rather than assuming every hesitation has a dollar sign attached to it. If the buyer trusts you, understands the product, believes it will work, and still rejects the economics, price deserves scrutiny.

A useful trust diagnosis has three parts.

First, identify the specific consequence the buyer appears unwilling to accept. Not “they don’t trust us.” What might go wrong from their perspective?

Second, identify what evidence would reasonably change their estimate of that risk. Not what would make the company look more impressive. What would actually help them decide?

Third, determine whether you can provide that evidence or reduce the risk without destroying the business you are trying to build.

That last part matters because some buyers will require evidence you do not yet have. A large company may require controls that are unreasonable for your current stage. A prospect may want references you cannot honestly provide. Someone may require support commitments that would make the account uneconomic. A buyer may simply need a level of institutional certainty that a young company cannot yet supply.

You are allowed to discover that.

Commercial diagnosis is not the art of turning every no into a yes. Sometimes the result is: This buyer requires more trust than we can credibly supply right now.

That is useful information. It may change the first market you pursue, the scope of the offer, the evidence you need to accumulate, or the commitment you ask for. It may also tell you to find a buyer whose risk is proportional to the evidence you actually possess.

Before leaving this chapter, do one uncomfortable exercise. Look at your product from the buyer’s side and write down the five strongest reasons a rational person might hesitate to trust the purchase even if they genuinely liked what the product did.

Do not write the objections you already know how to answer. Write the ones you hope nobody asks.

Maybe the company is new and important knowledge lives with one person. Maybe the application requires unusually broad permissions. Maybe the support process is effectively “message me.” Maybe the buyer would struggle to recover their data if the company disappeared. Maybe the claims are stronger than the current customer evidence. Maybe there is no obvious reason to believe the product will still be supported a year from now.

The purpose is not to become pessimistic about your company. It is to see the purchase the way a skeptical buyer might.

A builder naturally knows everything that makes the product safer than it looks. The buyer sees only what has become observable. The gap between those two perspectives is where trust problems live.

Once you have listed the strongest reasons a rational buyer might hesitate, there is a harder question to ask. Not whether you can explain them away. Whether the purchase survives them.

That is the next test.