Skills as an interviewer hears them
Skill lists are easy to write and hard to grade. This one is organised by what you would say in the room, with a weak answer beside a strong one for each skill, because the distance between those two sentences is what a hiring committee argues about.
| Skill | Weak answer sounds like | Strong answer sounds like |
|---|---|---|
| AI fit | "We could use AI to make this smarter." | "Reading receipts suits a model. Applying spend policy stays a rule, because an error there moves money." |
| Evaluation | "We'd measure accuracy." | "Two hundred labelled cases, yes-or-no pass rules, a judge checked against my labels, results reported by language." |
| Launch decisions | "Ship when quality is good enough." | "Ship at 90% overall with no segment under 80%, behind a flag, rolled back if complaints double." |
| Unit economics | "Costs will come down." | "Four cents per successful task, thirty tasks a user a month: $1.20 against a $10 plan." |
| Failure design | "We'd add a disclaimer." | "Low-confidence answers show sources and offer a person. Actions over $100 need a confirm." |
| Technical fluency | Lists techniques | Says which technique changes the decision: retrieval for fresh facts, fine-tuning for format and tone |
| Safety and governance | "We'd follow responsible AI principles." | "The agent can read mail but sending needs approval, because injected instructions arrive by email." |
| Prototyping | Describes what they would build | Builds a narrow version, runs five real inputs through it, and says what broke |
The two skills most often missing
Evaluation and metrics. PMs from classic backgrounds tend to treat quality as a feeling and cost as an engineering concern. In AI products both are product decisions with numbers attached, and interviewers press on them hardest because a launch bar or a margin plan cannot be bluffed past the second follow-up.
How much technical depth is enough
Enough to say which technical choice changes a product decision. Be ready to explain why a longer context window does not replace retrieval over a large document set, why a provider's model update can change your product's behaviour with no code change on your side, and why speculative decoding speeds responses at light load but helps little when servers are busy. You do not need to derive attention or tune hyperparameters.
Deciding without full information
Most AI PM questions have no clean answer, and the follow-ups add constraints until your first plan breaks. Interviewers are watching how you decide anyway. Name what you would want to know, pick the default you would act on without it, and say what evidence would change your mind.
"It depends" with nothing after it is marked Weak in every rubric on this site.
Building the skills
Practise each one as a spoken or written answer, not as reading. Every question here ends with a How it's scored section with Weak, Hire and Strong Hire lines. Write your answer first, then grade it against those lines before you read ours.
Sources and further reading
Questions about this topic
Evaluation: defining what good output means for a task, measuring it on real examples, and deciding when the number is good enough to ship. Launch, pricing and model choice all depend on it.