The criterion that decides the purchase is rarely named in discovery. Buyers state functional requirements and decide on implementation risk. The real criterion usually sounds like doubt, which is not something a buyer volunteers to the person selling to them — so it surfaces after the loss, if at all.
What do buyers say they want?
Functional requirements, mostly, expressed as a list. That is what a requirements document contains and what discovery is designed to elicit, and it is genuinely part of the decision.
It is rarely the deciding part, because by shortlist stage most vendors meet most stated requirements — a fact your own customers cannot tell you, having already chosen you.
The list is still worth having. It is how a buyer organizes the comparison, it is what the internal case will be written against, and failing to meet it removes you before the deciding criterion is ever reached. The error is treating it as the decision rather than as the entry condition, and that error is built into most discovery frameworks.
What actually decides the deal?
Confidence about implementation more often than capability. Whether this vendor will make the buyer's team successful, whether the project will finish, whether the buyer will look competent for having chosen them.
Those are risk assessments about the buyer's own situation rather than judgments about the product, which is why a feature-by-feature comparison misses them.
The implication is that the competitor to beat is frequently not another vendor. It is the option of doing nothing for another year, which carries no implementation risk at all and is what a cautious buyer defaults to when nobody has addressed the risk directly. Deals recorded as competitive losses are often losses to that.
Why is the real criterion unstated?
Because saying it aloud sounds like doubt — about the buyer's team, their internal politics, or whether the project survives a budget review. None of that is something a buyer volunteers to a supplier.
It is not evasion. It is a reasonable reluctance to discuss internal fragility with someone who is selling.
There is a second reason it stays unstated: naming it invites the vendor to solve it, and a buyer who has not decided is not ready to have it solved. Raising implementation risk early commits them to a conversation about their own readiness, which is a conversation they would rather have internally first.
How do you find it earlier?
Ask about the last comparable project and what went wrong with it. Buyers describe their own history freely, and the risk they are managing this time is usually visible in it — which is also why a lost-deal interview gets further than a lost-deal form.
Independent research reaches things discovery cannot, because the constraint is who is asking rather than how well.
The other route is sideways. People who have left the buyer's organization, implementation partners who worked on the last comparable project, and vendors selling adjacent products into the same team will describe the internal situation with a candor the buyer cannot offer to someone selling to them. None of that requires the buyer's participation.
What should the team do differently?
Address the unstated criterion unprompted. If implementation risk decides deals and buyers never raise it, the vendor who raises it first has demonstrated that they understand the situation.
That is an enablement change rather than a product one, and it is usually cheaper than the alternatives being considered.
The change is testable, which is unusual for enablement work. If implementation risk decides deals, a script that raises it in the first meeting should change the shape of the pipeline rather than the win rate alone: fewer deals reaching late stages and dying there, more disqualified early. That is a prediction worth checking rather than assuming.