Product interviews rarely test whether you know what a roadmap is. They test whether you can say what you decided, why, and what you gave up — in an organisation where almost every decision was made by several people at once. Most weak answers are not wrong; they are unattributable.
What this round is actually assessing
Ownership under shared credit
Product work is collaborative, so interviewers listen for the boundary between what the team did and what you did. "We decided" is the most common way a strong candidate sounds weak.
Decisions with incomplete information
They want the shape of the uncertainty — what you did not know, what you did about not knowing it, and when you decided to stop waiting.
Trade-offs you can name
Every real decision cost something. An answer where nothing was given up describes a decision nobody had to make.
Outcome, or the honest absence of one
"I do not have the number, but here is what we watched and what changed" is a strong answer. An invented metric is the only answer that cannot be recovered from.
The questions, and what each one is for
“Tell me about a product decision you made with incomplete data.”
Why they ask it
To find out whether you can act without certainty, or whether you wait for research to make the decision for you.
What a strong answer contains
Name what was unknown, what it would have cost to find out, what you decided anyway, and what would have made you reverse it.
The follow-up a vague answer earns
“What would have had to be true for you to make the opposite call?”
The mistake it catches
Describing a decision that was obvious in hindsight. If the answer contains no risk, it was not made under uncertainty.
“Describe a time you said no to a stakeholder who outranked you.”
Why they ask it
To test whether you can hold a position without turning it into a conflict story, and whether you understood their problem well enough to refuse it properly.
What a strong answer contains
What they wanted, what problem sat underneath it, what you offered instead, and how the relationship was afterwards.
The follow-up a vague answer earns
“What did you offer them instead of the thing you refused?”
The mistake it catches
Telling a story where you were simply right. Interviewers hear a lot of those and learn nothing from them.
“Give an example of a product that failed and what you learned.”
Why they ask it
To see whether you can be specific about your own contribution to a bad outcome without either hiding it or performing contrition.
What a strong answer contains
The decision you would make differently, stated plainly, and what you have done since that shows it stuck.
The follow-up a vague answer earns
“Where would you have caught it earlier?”
The mistake it catches
The humblebrag failure — "we shipped too fast because we cared too much". It reads as an unwillingness to answer.
“Walk me through how you decided what to build next.”
Why they ask it
To hear a real prioritisation process rather than a framework. Anyone can name a framework.
What a strong answer contains
What was on the list, what you compared them on, who disagreed, and what you dropped.
The follow-up a vague answer earns
“What was the strongest thing you decided not to do, and why?”
The mistake it catches
Reciting a scoring model. The interesting part is the judgement the model did not settle.
A made-up answer, made specific
“Tell me about a time you worked with a team that disagreed with your decision.”
The vague version
We were migrating off an old system and support had concerns, so we got everyone in a room, talked it through, and eventually we all agreed and it went pretty smoothly.
What is missing
Nothing here is yours. The concerns are unnamed, the room resolved itself, and "pretty smoothly" is the only outcome. An interviewer cannot tell what you did.
The stronger version
Support pushed back because the cutover would land in their busiest fortnight and they would carry the tickets. I had assumed the risk was technical; it was staffing. I moved the cutover two weeks and cut the scope of the first phase so their queue stayed flat. We lost a quarter of the migration from that release. I do not have the ticket numbers to hand, but the escalation path we agreed was not used once that month.
Written as an illustration. It is not a customer, a transcript, or a result we measured.
Three questions worth asking them
“What is the decision this role owns that the person before it did not?”
“Where does product disagree with engineering here most often, and how does that usually end?”
“What would make you say, six months in, that this hire went well?”
Practise these against your own résumé
Add your résumé and the job description and the questions change: they ask about your work, by name, and the feedback quotes what you actually said.