Zhang Pinpin · Hands-On AI Coach
← Back to home

Building AI Products—It's Not About the Tech

Long-Form Video · EP0091 September 2, 2026 02:45
What this episode covers

When it comes to getting AI built into real products, what matters is insight and how you design your solution. Most of the time it doesn't even get to the point where technical capability is the bottleneck. Take voice input as an example—plenty of big companies ship voice features powered by perfectly good models, and the products are still painful to use.

Three experience problems, three root causes, three fixes. Not one of them required a better model. Every single one came down to whether someone had thought it through.

When it comes to getting AI built into real products, what matters is insight and how you design your solution. Most of the time it doesn’t even get to the point where technical capability is the bottleneck. Take voice input as an example—plenty of big companies ship voice features powered by perfectly good models, and the products are still painful to use. I’ve built this myself, hit these walls myself, and what I found is that every problem that made the product feel broken could be fixed without stronger tech. The fixes just required someone to actually think about what was going wrong.

Here’s the first one. You press a hotkey to start voice input. You assume pressing the key and speaking happen at the same time. But sometimes your hand is slower than your mouth, and on top of that, the speech recognition service needs a moment to establish a connection. The result: the first two characters you say get dropped. Your sentence starts with a hole in it, and no matter how accurate the rest of the transcription is, the user’s reaction is “this thing doesn’t work.” But why does this happen? Is the model not good enough? No—it never heard those two characters in the first place. This isn’t a technology problem. This is an insight problem. The fix is simple: keep the input listening all the time, and when the user presses the key, process what was said just before the keypress along with everything after it. No model swap, no extra compute. You just need to realize that hands are slower than mouths.

The second pain point is even more common. A lot of voice input tools wait until you finish speaking before they process anything. You sit there staring at a blank screen, wondering if your words went anywhere. Why do they do this? Usually to get better accuracy. Speech recognition models come in two flavors—full-utterance recognition takes the entire sentence, processes it as a whole, and can use prompt context and a hot-word list to correct mistakes; streaming recognition transcribes character by character, and while it’s reasonably accurate, errors do creep in. Most products pick full-utterance recognition because it’s more accurate, and the trade-off is that dead air after you stop talking. The fix is straightforward and doesn’t need any exotic tech: use streaming recognition first so characters appear one by one and the user can see “okay, my words are going in.” Yes, there will be errors on screen. But the moment you finish speaking, run the whole thing through full-utterance recognition to revise it. That revision takes roughly half a second to one second—users don’t even notice. The experience gets dramatically better. Both model types are off-the-shelf. Anyone can call them. The only difference is whether you thought to chain them together.

The third problem grows directly out of the second. Full-utterance recognition lets you inject a hot-word list to fix homophones, proper names, and jargon. But where do those words come from? The traditional approach is a personal hot-word dictionary that users maintain themselves. In practice, normal users never bother. So the system auto-detects and adds likely hot words over time. The problem is that once that list passes a certain size—say, more than a hundred words—the noise it introduces outweighs the corrections it makes. Accuracy actually gets worse. This isn’t a model limitation; it’s a dictionary-management problem. The fix isn’t to iterate on the model. It’s to make the hot-word list dynamic—shaped by the context the input tool is operating in. If you’re inside an agent-based application, for instance, the system can pull from that project’s memory and inject a hot-word list tailored to exactly this environment: every person’s name and technical term that has come up in the project so far. The result is really good. And again, the model didn’t get stronger. You just fed it the right words at the right time.

Step back and look at all three. Not one fix required training a better speech model. Not one required throwing more compute at the problem. Every bottleneck was the same thing: had someone thought carefully about where the user was actually getting stuck? The underlying tech is the same tech everyone has access to. The APIs a big company can call, you can call too. Whether the product feels good to use comes down to whether you had the insight.

So here’s what I keep saying: building a good AI product—you’re nowhere near the stage where tech is the deciding factor. The best technology gets pushed forward by genius and resources. The best insight and solution design is a skill you can train yourself.

The best tech gets pushed forward by genius and resources. The best product insight is a skill you can train yourself.