Most AI products fail before they ship. Not because the model is wrong, not because the infrastructure is too expensive — but because the team skipped the hard thinking and went straight to building.
I’ve been building with AI since before it was the thing everyone was building with. I’ve seen the pattern repeat: smart people, real budget, genuine ambition — and a product that never quite works in the real world. This is my attempt to give you the map I wish I’d had earlier.
Why Most AI Products Fail
Here’s the uncomfortable truth: most teams treat AI as a feature before they understand the problem it’s solving.
They see what GPT-4 can do in a demo, convince themselves it applies to their use case, and start engineering before anyone has asked the hard questions. The result is an AI-shaped layer on top of a problem that either wasn’t solved by the non-AI version either, or didn’t need AI at all.
The failure modes cluster around three things:
1. Optimising for wow over utility. The demo is great. The model responds coherently, the UI is slick, the investor call goes well. Then real users arrive and the cracks show. They ask questions the model wasn’t tuned for. Edge cases multiply. The product works 80% of the time, which in most contexts is worse than a simpler tool that works 95% of the time.
2. Treating latency and reliability as engineering problems only. Your PM instinct might say “we’ll fix performance later.” In AI products, that instinct is wrong. Users form their trust relationship with an AI product in the first five interactions. A slow, inconsistent response in session one can kill retention permanently — regardless of how much better it gets in week three.
3. Ignoring the human in the loop. The best AI products I’ve worked on all had a clear model for when the AI should act, when it should ask, and when it should get out of the way entirely. Teams that never define this end up with products that either do too much autonomously (and get things wrong in ways that erode trust) or interrupt users constantly (and become annoying faster than any competitor ever could).
The Right Starting Questions
Before you write a line of code or pick a model, answer these four questions honestly:
What is the specific human task this replaces, augments, or accelerates? Not a category. A task. “AI for customer support” is not an answer. “Drafting the first response to a refund request so a human agent can review and send in under 30 seconds” is an answer. Specificity here is everything.
Where does the AI need to be right, and where can it be approximately right? AI products are probabilistic by nature. That’s fine for some use cases and catastrophic for others. A product that helps a PM draft a PRD can tolerate hallucinations that a human will catch. A product that flags compliance risks in legal contracts cannot. Know your error tolerance before you commit to a model architecture.
What does failure look like to the user? Not what does a failed API call look like — what does the user experience when the AI gets it wrong? Do they know it’s wrong? Can they correct it? Does a wrong output cascade into something worse? Map the failure experience before you design the success experience.
What does the non-AI version of this look like? If you can’t describe the manual or rule-based version, you don’t understand the problem well enough to build the AI version. This isn’t a rhetorical question — the non-AI version is often your fallback, your eval baseline, and your user’s mental model all at once.
A Practical Framework for Building AI Products
This is what I use. It isn’t academic — it’s what I’ve iterated to after shipping things that worked and things that didn’t.
Step 1: Define the unit of value
AI product management best practices usually start with user stories. I start differently: I start with the unit of value the AI produces.
For a writing assistant, is the unit a complete draft? A single sentence? A structural suggestion? For a customer service bot, is it a resolved ticket? A deflected contact? A satisfied user?
The unit of value determines your eval criteria, your success metric, and your roadmap priorities. Everything downstream from here is easier when this is sharp.
Step 2: Build the eval before the product
This is the move most teams skip, and it’s the one that saves the most time.
Before you build the product, build the thing that tells you whether the product is working. This means: a set of real (or realistic) inputs, the outputs you expect, and a scoring mechanism. It doesn’t have to be automated on day one. A spreadsheet with 50 test cases and a human grader is infinitely better than shipping and waiting for support tickets.
When the eval exists before the product, every model change, prompt change, and architecture decision has a ground truth to test against. Without it, you’re flying blind and calling it iteration.
Step 3: Design the trust boundary explicitly
Every AI product has a trust boundary: the point at which the AI’s output becomes consequential enough that a human should review it before it has effect.
Design this on purpose. Don’t let it emerge from your implementation. Some products should have the trust boundary at “never” (AI drafts, human always reviews). Some can push it to “usually” (AI acts, human reviews on request). Very few should be at “always” (AI acts autonomously, no review path).
The right answer depends on your domain, your error tolerance (see starting question #2), and your users’ existing trust in automation. The mistake is never deciding.
Step 4: Ship the smallest thing that tests the real constraint
The real constraint is almost never the model. It’s the data pipeline, the user workflow, the latency requirement, the regulatory environment, or the cost at scale.
Ship the smallest version that puts the real constraint under load. Not the real constraint as you imagine it — as it actually exists in your production environment, with your real users, doing your real task.
I’ve seen teams spend three months fine-tuning a model when the blocking issue turned out to be that users didn’t trust AI output unless it showed its reasoning — a prompt engineering fix that took two days. Build to find the real constraint fast.
Step 5: Instrument everything from day one
AI products have a data flywheel that traditional software products don’t. Every user interaction is a potential training signal, an eval case, or a trust-calibration datapoint.
But only if you collect it.
From the first production user: log inputs, log outputs, log corrections, log abandonment. Don’t wait until you have scale to care about data quality. The decisions you make about data collection in the first month determine what you can do in month six.
Common Traps (That I’ve Fallen Into Myself)
The context window trap. When the model has a large context window, it’s tempting to throw everything in and let the model figure it out. This works in demos. In production, it increases latency, increases cost, and often decreases output quality because the signal-to-noise ratio drops. Be ruthless about what goes into context.
The prompt engineering treadmill. Prompts are not a stable foundation. A prompt that works perfectly today can degrade with a model update, a change in user behaviour, or even drift in the distribution of inputs over time. Treat your prompts like code: version them, test them, review changes. If your product’s quality lives entirely in an unmarked string in your codebase, you’re one deployment away from a regression you can’t explain.
The cost model surprise. Token costs are predictable. Usage patterns are not. A feature that costs $0.02 per interaction sounds cheap until your power users hit it 300 times a day. Model your cost per user segment, not just per call — and build cost controls before you need them.
Confusing technical capability with product-market fit. The model can do it. That doesn’t mean users want it, trust it, or will pay for it. These are different questions. Capability is a necessary condition for an AI product, not a sufficient one. Keep testing the PMF assumption even when the demo is impressive.
Skipping the edge case conversation. Edge cases in AI products aren’t just technical edge cases — they’re the inputs your users will actually produce that your happy-path design didn’t anticipate. Run a structured edge case session with real users early. What’s the weirdest thing they’d try? What happens? Is it acceptable?
The Short Version
Building AI products well is a practice, not a formula. The teams that get it right share a few habits: they define specificity before they define architecture, they build evaluation infrastructure before they build product, and they treat trust as a design constraint — not an afterthought.
The teams that struggle are usually moving too fast to stop and answer the hard questions. Speed matters in product. But in AI product development, the questions you skip at the start have a way of becoming the crises you manage at the end.
Work With Me
If you’re a founder or PM building your first AI product and want a practitioner in your corner — for strategy, architecture review, or hands-on build support — let’s talk.
And if you’d rather start with the writing: I publish Ship It, a newsletter for people building with AI. Short, opinionated, no filler. Sign up here.
