Why Building AI Products Is Fundamentally Different

Discovery looks different when the output is probabilistic

In a conventional product, discovery is about understanding user needs and then designing a deterministic system to meet them. You know what the button will do. You know what the form will accept. The contract between design and engineering is specific.

With AI, that contract breaks. You're building something that will behave differently across users, edge cases, and time. Discovery isn't just about "what does the user need" — it's also "what does good output even look like, and how consistent does it need to be?" Those are genuinely hard questions, and most user research methods weren't designed for them.

I've found that the most useful discovery work for AI products isn't just about intent — it's about tolerance for failure. How wrong can the model be before the user loses trust? That answer varies wildly across users, use cases, and stakes. You need to know it before you scope anything.

Feedback loops are slower and murkier

In most products, you ship, you measure clicks or conversions or retention, and you iterate. The signal is relatively clean. In AI products, the feedback loop is almost always delayed and ambiguous.

A user who gets a bad model response might not click a thumbs-down button. They might just leave. Or they might accept an incorrect output because they don't know enough to question it — which is the worst outcome, and the hardest to detect. You need proxy signals: session depth, follow-up questions, re-runs of the same query, correction behaviors. None of these are in your standard analytics dashboard.

The implication: you need to design instrumentation into the product from day one, not bolt it on after launch. The data model for an AI feature is part of the product spec.

Model uncertainty is a PM problem, not just an ML problem

This is the one that surprised me most. In my experience, PMs tend to treat the model as a black box and assume ML engineers will handle uncertainty. That's a mistake.

Model uncertainty — the situations where the model doesn't know what it doesn't know — has direct product consequences. It shapes where you put confidence indicators, when you fall back to human review, how you communicate limitations to users, and what happens at the edge cases no one thought to test.

If you don't understand the failure modes of the model you're building on, you can't write the right acceptance criteria. You end up with a spec that works for the happy path and breaks everywhere else.

What this means for how I work

I've stopped treating AI product work like feature work with a machine learning component. It's its own discipline — one that requires a closer relationship between PM, ML, and data than most teams are used to. It requires designing the measurement system as carefully as the product itself. And it requires being honest with stakeholders that "done" means something different when the output is generated, not programmed.

The good news: when you get it right, AI products create value in ways traditional software simply can't. The complexity is real, but so is the ceiling on what's possible.