How to Think About AI in Your Product | Abhishek Goyal
There is a predictable pattern in early-stage companies right now. Someone sees a competitor announce an AI feature, or has a few useful conversations with ChatGPT, and comes away with a broad conclusion that the product now needs AI. The request then lands with engineering as a vague mandate: add AI, make it smart, make it look modern.<br>That is understandable. It is also a poor way to make product decisions.<br>AI is a real and useful set of technologies. It is not magic, and it is not a product strategy by itself. AI systems introduce risks distinct from those of conventional software, and those risks need to be managed deliberately rather than waved away in the excitement phase. AI product decisions should be evaluated through user value, business impact, and implementation reality, not through novelty alone.<br>For product leaders, the useful question is usually not “how do we add AI?” It is “what problem are we trying to solve, and can AI solve it better?”<br>That change in framing saves time, money, and credibility.<br>Start with the product problem<br>A proposal should survive contact with plain product thinking before it is allowed to become an AI initiative.<br>The first test is simple: if this idea did not involve AI, would it still sound like a sensible feature? If the answer is no, there is a good chance the team is dressing up a weak product idea in fashionable language. A feature that has no user value without AI usually has no user value with AI either.<br>A few questions help expose this quickly:<br>What user problem does this solve?<br>For which user, in which workflow, at which point of friction?<br>What changes for the user if this works well?<br>How is that change measured: time saved, error reduced, revenue improved, conversion lifted, support volume reduced, retention improved?<br>What is the non-AI version of the same feature?<br>That last question matters. Product features should be discussed in terms of outcomes, not in terms of implementation fashion. Nobody should be proposing “let’s do this with Python” or “let’s do this with Java” as a product idea. Those are engineering choices. “Let’s do this with AI” often belongs in the same category.<br>The right sequence is:<br>Define the problem.<br>Define the desired user and business outcome.<br>Explore candidate solution approaches.<br>Only then decide whether AI materially improves the result, speed, cost, or feasibility.<br>Check whether AI is actually needed<br>Some features are better because of AI. Many are merely adjacent to AI.<br>That distinction matters because traditional software is still better when the task is deterministic, the rules are stable, the inputs are structured, and correctness needs to be exact. AI tends to earn its place when the task involves ambiguity, messy unstructured inputs, summarization, extraction, classification, ranking, language interaction, or generating first drafts that a human can verify and refine.<br>A useful test is to place the idea into one of four buckets:<br>BucketDescriptionTypical answerDeterministic problemClear rules, structured inputs, exact outputs requiredUse conventional software firstAI-assisted problemAI improves speed or usability, but a non-AI flow can existConsider AI as a layer, not the coreAI-native problemThe core value depends on language, prediction, or probabilistic reasoningAI may be centralMarketing checkboxThe feature exists mainly because the market expects to see “AI”Keep scope tight and risk controlledMany proposals become much clearer once they are classified honestly.<br>If the proposal sits in the first bucket, adding AI may make the result less predictable and more expensive than necessary. If it sits in the fourth, that does not automatically make it invalid. Sometimes a market requires a visible AI story. But in that case the team should say so explicitly, keep ambition modest, and avoid pretending the feature is strategically transformative.<br>Separate user demand from internal excitement<br>Internal enthusiasm is not evidence of user demand.<br>A lot of AI ideas are appealing because they are easy to imagine in a product review meeting. They are much less compelling when placed inside an actual customer workflow. The most useful discipline here is to ask what users are already trying to do, what they complain about, and what they currently spend time or money on.<br>Have customers asked for this directly?<br>If not directly, have they described the pain that this feature would solve?<br>Would users change behavior to use it?<br>Would they trust it enough to rely on it repeatedly?<br>If the feature disappeared after six months, would anyone be upset?<br>Features built mainly for demos often fail this test. They attract attention once, then sit unused because they are interesting but not embedded in a recurring job to be done.<br>That does not mean every AI feature must be deeply utilitarian. Some are legitimately...