Product Diligence Before Product Development

No serious investor buys a company without diligence. The financials are read. Customers are called. Contracts are reviewed, liabilities surfaced, and the price moves with the evidence. Nobody calls this excessive. It is simply how capital behaves when it is being careful.

Yet every year, experienced operators — people who would never skip diligence on an acquisition — commit meaningful capital to software products with no diligence at all. A conviction forms. A vendor is found. A contract is signed. The discipline that governs every other investment is suspended for the one asset with no track record: the product that does not exist yet.

Two different problems

Diligence on a company is verification. The business exists. It has revenue, churn, contracts, staff, and a history that can be audited. The question is whether the record is true and whether the price is right. The evidence is in the data room.

Diligence on a product that does not exist is a different problem in kind. There is no record to verify. You are not auditing the past — you are testing a claim about the future: that a specific buyer, facing a specific pain, will pay a specific amount to solve it, and keep paying.

That claim can be tested. The evidence exists — it is just not in a data room. It sits in workflows, buyer behavior, substitute products, pricing pressure, patent filings, and market structure. Gathering it is a research problem. Skipping it is a choice.

Consider what an acquisition team would do with a target's revenue claim: trace it to contracts, call the customers behind it, test the churn. Product diligence applies the same instinct to a forward claim. If the pitch says "operators lose four hours a week to this," the diligence question is: which operators, observed where, paying what today, to whom? A claim that cannot be traced to observable behavior is not evidence. It is a hope with formatting.

A feature list is not evidence

Most builds begin with a feature list. It feels like progress. It is actually the moment the project quietly loses discipline, because a feature list is a set of opinions about a solution, recorded before anyone has established the problem.

A feature list tells you what the owner believes. It says nothing about whether the buyer agrees, how often the pain occurs, or what anyone currently pays to tolerate it. Vendors like feature lists because they can be priced and delivered. Evidence cannot be invoiced as neatly.

There is a second problem, quieter and more expensive. A feature list fixes the solution before the research has run, so every subsequent decision — architecture, budget, timeline, hiring — inherits the original guess. By the time the market delivers its verdict, the guess has been laundered through eighteen months of professional-looking process. It no longer feels like a guess. It feels like a plan that deserves one more release.

Features are opinions. A thesis is a claim you can test before capital moves.

What a product thesis must contain

Before development, the opportunity should be reduced to a thesis — one page, five commitments, each one falsifiable:

• A named buyer. A role with a budget and the authority to spend it. "Businesses like mine" is not a buyer.
• Pain frequency. Daily and weekly problems get budgets. Quarterly irritations get workarounds.
• Willingness to pay. Evidenced, not assumed. What does the buyer spend today — in money, hours, or errors — to live with the problem?
• Switching cost. What must the buyer stop doing to adopt the product, and what does that disruption cost them?
• A distribution path. How the first twenty customers are reached, by name. Hope is not a channel.

If any element cannot be stated, that is not a formatting gap. It is a finding. It tells you exactly where the research must go before a build can be defended to anyone — including yourself.

"Do not build yet" is a result

The most useful output of product diligence is sometimes a decision not to proceed. This runs against the instinct of everyone selling development work, which is precisely why it matters.

When diligence stops a weak build, the return is the entire budget the build would have consumed — plus the year of attention, plus the credibility spent on a product the market ignored. Operators understand this in every other context. Walking away from a bad acquisition is not failure. It is the diligence working.

The base rates justify the discipline. Most new software products fail commercially, and the dominant cause is not engineering. It is building something the market did not ask for, for a buyer who was never named, against a switching cost nobody priced. Every one of those failures was preventable at the thesis stage, for a small fraction of what the build consumed.

A build partner who cannot say "do not build yet" is not a partner. They are a supplier with your risk on their order book.

Where AI belongs in this

AI has changed the economics of the research, not the nature of the decision. Work that once took a research team a quarter — mapping competitors, indexing patent fields, structuring buyer groups, surfacing contradictions in the evidence — now compresses into days. That compression is real, and we use it hard.

What AI does not do is decide. It cannot weigh a founder's distribution advantage against an adoption risk, or judge whether a switching cost will hold under a competitor's discount. Pattern recognition is machine work. Product judgment is senior, human, and accountable. Any process that confuses the two is outsourcing conviction to a model.

The sequence is not complicated. Evidence first. Thesis second. Working software third — small, fast, and honest. Capital last, and only when the thesis survives contact with real buyers. That is diligence, applied to the one asset class where most people skip it. You apply it to every other investment you make. The product deserves the same.