What Changed My Mind About Problem Interviews (AI SaaS)

I used to skip problem interviews for AI products. The capability was the point. The model was impressive. The demo got retweets. Why slow down to talk to people? Several quiet launches later, I changed my mind. Here is what actually did it.

It Was Not the Quiet Launches

Failed launches did not change my mind. I rationalized them. The model was not strong enough yet. The marketing was wrong. The audience was distracted. There was always a story that did not require interrogating the underlying premise.

If you have only shipped one AI product that flopped, you can probably explain it the same way. The denial is comfortable.

What Actually Did It

One conversation. With a customer who tried our product for two days and stopped. I asked why. They said: "The output was good but I had to verify everything anyway. So I might as well have written it myself."

That sentence broke open the entire failure mode. The product produced correct output. Customers still abandoned. The reason was not output quality. It was that we crossed the trust boundary - we generated content that the customer could not skip-verifying, which meant the productivity gain was zero.

The Specific Realization

The customer was telling me, in plain language, that the trust boundary was the entire game. The model could be perfect and the product could still fail because the verification step the customer did not skip was where the time went.

I had built a capability without understanding the boundary. The capability was wasted. Not because it did not work, but because it operated on the wrong side of where the customer drew the line.

The Cheaper Version of That Realization

I should have engineered ten of those conversations on purpose, before building, instead of stumbling into one accidentally after launch. The trust boundary was discoverable in any problem interview round that asked "where do you check the output by hand." I had not asked. I had assumed.

The realization was not that interviews are good. It was that the conversation that explained my failed launch was reproducible on demand, and I had been refusing to reproduce it.

The AI-Specific Pattern

This pattern is unique to AI SaaS. Non-AI products fail when the feature is wrong. AI products often fail with a working feature, because the feature operates outside the customer's trust zone. The feature is correct. The boundary was wrong.

Problem interviews map the boundary. Without them, you are guessing where the customer will and will not skip verification - which is the actual product spec, not a side detail.

What I Did Differently After

Every AI project since: at least ten interviews before training, fine-tuning, or even picking a model. The interviews tell me the boundary. The model selection happens after. Some interviews have killed ideas. Some have rearranged them. None have been wasted, especially the ones that killed ideas.

What This Means for You

If you are an AI SaaS founder reading this, you do not yet have the scar. The arguments above will not move you the way the scar would. The scar arrives, sooner or later, and it is much cheaper to take the lesson on faith now than to pay the tuition.

One conversation. One person. Before you train anything. That is the threshold of trying.