Alpesh Pawar: we don't need more AI features, we need better product thinking

Alpesh Pawar published this essay in the CodeToDeploy publication on Medium in May 2026. The central argument is one that resonates with anyone who has reviewed a backlog full of AI feature requests: novelty is not a problem statement. Teams that start from “AI can do X, so let’s add X” tend to build things that work in demos but fall apart in production, usually because no one has named what friction the feature is meant to remove, for which specific user, under which conditions.

The article examines a failure mode that has become more common as AI tooling gets cheaper: building AI features faster than users can trust them. When a feature produces varied or unpredictable outputs — which LLM-based features often do — users need strong mental models of when it works and when it does not. If the product team has not built those guardrails into the design, users either avoid the feature or blame the product when it misfires.

Pawar proposes a pre-build filter with four steps. First, reframe the feature request as a user problem. If you cannot write down the friction a specific type of user experiences in a specific workflow, the feature is not ready to spec. Second, examine whether a rule-based system or simpler UI improvement would solve the same problem — if so, the overhead of an LLM may not be justified. Third, define failure modes in advance: when the model produces a wrong answer, does the user know it, and can they recover? Fourth, establish success criteria in terms of user outcomes rather than model accuracy.

The article is also direct about production-readiness gaps that demos hide. Permissions, caching, latency under real load, data sensitivity, error handling, and asynchronous processing all require deliberate design for AI features. A wrong output that varies unpredictably is more disorienting to users than a consistent error they can learn to work around, so these concerns compound for probabilistic systems.

Pawar writes from a full-stack engineering perspective. The article is most useful for product managers who work closely with engineering teams and need a shared vocabulary for evaluating whether an AI feature is actually ready to develop. It is less a high-level strategic roadmap and more a quality filter for individual feature decisions — a useful complement to capability-first product thinking.