Why AI Product Managers Have Stopped Drawing Prototypes

A friend who recently switched to an AI product manager role was asked by a colleague how many prototype sketches he had produced; he handed over a stack of test‑case sheets, leaving the colleague stunned.

Many still view AI product management through the lens of traditional internet product work—writing PRDs and polishing pixel‑perfect prototypes—but the reality is quite different.

Since the AI product boom, former PMs often ask, "How detailed should the requirement document be?" The question itself is misguided.

Traditional software products are like building blocks with clearly defined parts; a PRD is a specification manual. In contrast, an AI product is more like raising a child—you cannot dictate that it must grow to exactly 1.8 m; you must iteratively assess and adjust its development.

The gap between a "usable" (60‑point) AI product and a "good" (100‑point) one becomes clear with examples: an intelligent customer‑service bot built on an open‑source API can answer simple queries like "business hours" or "address", but it fails when asked comparative questions such as "which return policy is better, ours or a competitor's?"

A 100‑point product must handle such out‑of‑scope questions reliably and consistently, not just once.

Consequently, AI product managers spend their time designing "exams" without standard answers. They create test items ranging from basic functional questions (e.g., "check weather"), logical‑reasoning tasks (e.g., "plan the optimal route from office to home avoiding rush hour and passing a market"), to deliberately tricky edge‑case queries (e.g., a string of emojis "🚗+⛽️+💡=?").

The role has evolved from drawing prototypes to constructing evaluation frameworks. Traditional PMs translate user needs into development‑readable documents; AI PMs act as "evaluation architects", understanding data pipelines, model execution, and potential labeling pitfalls.

Senior AI PMs now prioritize candidates who have designed complete evaluation systems over those with beautiful prototype portfolios.

This shift is forced by AI's flexibility—static requirements cannot guarantee success.

Consider an AI writing assistant that initially excels at drafting work summaries (a 60‑point product) but later produces a bland "thank you for your companionship" response to a breakup letter, revealing the limits of a "good enough" product.

The distinction between passive implementation (60 points) and active verification (100 points) underlies product quality.

One team collected recordings from 20 Sichuan speakers across age groups, amassing over 30 variations of the local phrase "shazi o" to improve dialect understanding—something a traditional PM would never do.

Effective test sets must include basic functionality, complex logical reasoning, and edge‑case scenarios, because users' imagination often exceeds the product's original scope.

When users pose an emoji combination like "🚗+⛽️+💡=?", the AI initially answers "I don't know"; after adding such "symbol questions" to the dataset, it gradually learns to respond correctly (e.g., "nearby gas station prices").

Machine‑based scoring using large models (e.g., GPT‑5) can evaluate thousands of questions quickly, yet it sometimes assigns high scores to nonsensical answers—such as rating "drink hot water" as a good response to "how to soothe a girlfriend"—requiring human review.

Analyzing wrong answers remains challenging; errors may stem from missing data, algorithmic confusion (e.g., mixing up "Apple phone" with "Apple fruit"), or awkward generation despite correct logic.

In a movie‑recommendation case, the AI recognized only the "suspense" tag and ignored the user's preference for "suspense with a female lead", highlighting the need for nuanced evaluation.

Evaluation is just the beginning. Teams must prioritize fixes based on impact—small issues are iterated quickly, while major model logic bugs may need dedicated algorithmic re‑tuning.

Weekly "mistake review" meetings bring together data, algorithm, and labeling teams to dissect failures, because an AI that is not closely monitored will repeatedly produce unsatisfactory results.

Cross‑team collaboration is crucial: developers may deem a 2% error negligible, while UX teams see a significant user‑experience hit.

The AI PM acts as a judge, using data to prioritize work—for example, addressing a problem that caused 30% of users to abandon the product.

Securing labeling resources is often necessary; a new scenario might require adding 5,000 data points to achieve reliable evaluation.

Relying on a single metric like accuracy is insufficient—users may find answers correct but overly verbose.

An AI education product that evaluated against a year‑old exam bank failed when the curriculum changed, leading to a flood of complaints.

Today, the market is ruthless: 60‑point AI products are being phased out. Users demand not just functionality but a delightful experience, which is achieved through the AI PM’s relentless cycle of designing, testing, and refining evaluations.