Back to posts

2026 - Colabra

Stop calling every customer conversation traction

A founder's evidence ladder for AI products: how to separate workflow pain, pricing signal, procurement movement, internal-build risk, pilot learning, and real traction.

There is a dangerous month in every startup where the calendar starts looking like proof.

The right logos are taking meetings. Senior people are asking smart questions. Buyers mention budget. Someone says the demo is interesting. Someone else asks for security documentation. A partner wants to package the product into a service motion. An enterprise team says they are building something similar internally.

It feels like traction.

Sometimes it is.

Usually it is evidence.

A customer conversation is not traction until you know what kind of evidence it produced.

That distinction sounds pedantic until it saves you from building the wrong company update, the wrong roadmap, or the wrong sales motion.

Meetings are evidence, not progress

A meeting means someone agreed to spend time.

That matters. It does not prove they have pain. If they have pain, it does not prove they own budget. If they own budget, it does not prove they can pass security. If they pass security, it does not prove the product beats the internal alternative. If the product beats the internal alternative, it does not prove they will change behavior.

Each step is a different claim.

The mistake is compressing all of them into one word.

Traction.

Founders do this because the narrative pressure is real. Investors want momentum. Teams want confidence. Advisors want a clean story. The founder wants the chaos to mean something.

But a clean story can hide the most useful learning.

The evidence ladder

Here is the ladder I use now.

Pain evidence: the buyer can describe a painful workflow in concrete terms. In diligence, this might be messy rooms, late documents, missing request-list items, workstream handoffs, or the fear of missing something material.

Workflow evidence: the buyer can show where the product fits into existing work. They know who uses it, when, and what output it replaces or improves.

Output evidence: the buyer can name the artifact they need. Issues list. Request-list coverage. Workstream report. Missing-item list. Executive summary. Disclosure-schedule support.

Pricing evidence: the buyer reacts to a number in a way that teaches you something. A vague "sounds reasonable" is weak. A concrete unit like file count, room size, deal stage, or project scope is stronger.

Procurement evidence: security, legal, vendor enrollment, data handling, and contracting begin. This can be a positive signal. It can also be where learning goes to die.

Usage evidence: real or representative material goes through the product and produces corrections, failures, and repeat behavior.

Conversion evidence: the buyer signs, pays, onboards, and keeps using the product.

Expansion evidence: the workflow spreads to more users, rooms, teams, or deal types.

Those levels should not be reported as the same thing.

Why this matters more in AI

AI products make evidence especially slippery because demos are easy to like.

A buyer can see an AI system summarize a document and believe the category is real. That does not mean the product is ready for the buyer's room, permission model, issue taxonomy, review process, or export format.

A large enterprise can validate your thesis and still be a bad first customer because they have an internal team building the same thing.

An advisor can love the workflow and still lack a repeatable way to sell it through to clients.

A sophisticated buyer can ask for a pilot and then judge it against Claude, Copilot, SharePoint, a junior analyst, outside counsel, or an internal tool. If your proof does not name the alternative, the result will be mushy.

That is why evidence classification belongs in the operating system of the company. It keeps the team honest about what has actually been learned.

Positive evidence can weaken strategy

The hardest evidence to handle is positive evidence from too many places.

An enterprise validates one use case. A service firm validates another. A lean buyer wants a narrow tool. A partner wants packaging. A power user wants more autonomy. A compliance-heavy buyer wants control. A sophisticated buyer wants to benchmark against internal AI.

Every one of those signals can be true. Following all of them creates mush.

This is the strategy problem I wrote about in How our pitch changed when our buyers got smarter. The market can get smarter faster than your positioning. Once that happens, broad AI language stops working and the company has to choose a sharper motion.

The calendar can be full and the strategy can still be unresolved.

That is a painful sentence. It is also useful.

Negative proof is underrated

One of the most useful customer conversations is the one where the buyer declines for a precise reason.

"We do not see enough incremental value above internal AI and SharePoint."

That kind of no is not failure in the usual sense. It is a benchmark.

It tells you what the proof needed to prove. It tells you the buyer's alternative. It tells you whether your product is being judged as a workflow system, a model wrapper, a services tool, or a nice-to-have.

Friendly ambiguity is less useful than a sharp no.

A sharp no gives the team a testable question: can we produce better coverage, better citations, faster review, lower burden, or a more usable work product than the buyer's current alternative?

If the answer is no, the sale should stop. The product should learn.

How I would report progress

If I were writing an investor update for an AI workflow company, I would avoid one blended traction paragraph.

I would break the evidence apart:

  • which accounts used real or representative material
  • which accounts advanced to pricing or packaging
  • which accounts started security or legal review
  • which conversations validated internal-build risk
  • which partner conversations created distribution signal
  • which proof designs failed and why
  • which segment now looks sharper than it did last month

That structure is less glamorous. It is more useful.

It also helps the team make the next decision. The goal is not to make every account sound exciting. The goal is to choose the next segment, proof, and product bet with less self-deception.

The sentence I keep coming back to

Customer evidence is only useful when it keeps its shape.

A meeting is a meeting. A pilot is a pilot. Procurement is procurement. Usage is usage. Payment is payment. Expansion is expansion. A no with a clear benchmark is a gift.

When you name each one accurately, the company gets smarter.

When you flatten all of it into traction, the story gets smoother and the strategy gets worse.