The concepts I mixed up in interviews: Discovery, Prioritization, Evaluation
我在面试里答串的概念 - AI PM 面试复盘 02- A few times in interviews I mixed things up: they asked about Prioritization and I was still talking about signal quality and validation; they asked about Discovery and I jumped too fast to value, cost and priority.
- Here’s how I tell the three concepts apart now: Discovery is about whether we found the right problem, Prioritization is about whether we ordered things right, and Evaluation is about whether the result met expectations.
- A customer request can count as a discovery signal, but it doesn’t prove the problem is real, and it doesn’t automatically land on the roadmap. In an interview, I first figure out which step they’re asking about, then answer.
In a few interviews, I mixed up questions that sit very close to each other:
Once, the interviewer had organized and clustered customer feedback, then asked, “How do you decide what to do next?” I kept going on about signal quality and validation. They reminded me: they were asking about Prioritization.
Another time, they asked: faced with an open problem space, how do you find the problems actually worth solving? My answer went too quickly into value, cost and priority. Only looking back did I realize they were asking about Discovery.
Back to the full flow:
Goal / Outcome → Problem Discovery → Opportunity Set → Prioritization → Solution Discovery → Delivery → Evaluation / Measurement → Iteration
Real work is never this linear, but it’s a good way to locate the question.
01 | Discovery: which problems are worth solving?
Look for recurring patterns in signals from users, data, support / ops feedback, workarounds and so on, separate the surface-level request from the deeper problem, then validate whether it’s real and whether it matters.
02 | Prioritization: of the problems worth solving, which comes first?
The problems mostly hold up, but resources are limited. Now you compare must-dos, user and business value, urgency, strength of evidence, engineering cost, dependencies and risk.
At its core, it’s making trade-offs under limited resources: if this moves up, something else has to move down.
03 | Evaluation: once it’s built, is it actually good?
Check whether the result meets the success criteria.
A regular product might look at conversion and retention; an AI product also looks at accuracy, groundedness, human override, latency and cost. You run evals before launch, and after launch you still have to watch how it performs in real use.
All three concepts shape “what we build,” which is why they’re so easy to mix up.
Right now I keep it simple:
- Discovery: did we find the right problem?
- Prioritization: did we order things right?
- Evaluation: did the result meet expectations?
A customer request can be a discovery signal, but that doesn’t prove the problem is real, and it doesn’t automatically earn roadmap priority.
In an interview, first figure out which step they’re asking about, then answer.
Written in Chinese and translated into English with the help of AI. Read the original