Anchor on the PM/PO role and concrete practices. Mention backlog grooming, sprint planning, demos with stakeholders, and retrospective-driven improvement. If you have an AI context, highlight how Agile was essential for iterating on model quality — requirements that can only be fully validated once the model runs on real data.

"I pull it out — full stop. An unrefined story in a sprint leads to mid-sprint clarification storms, scope creep, and missed commitments. My rule: no story enters a sprint without clear acceptance criteria, defined scope, and no unresolved dependencies. That's what refinement sessions are for. If something urgent comes up at the last minute, I either time-box a spike to investigate it, or defer it to the next sprint."

"Documentation serves a reader. I ask: who reads this, when, and what decision does it support? That determines the appropriate level of detail. For a fast-moving PoC, a one-page problem statement and success criteria is enough. For a production AI feature in a regulated industry, I write a full BRD with model specs, data governance notes, and audit trail requirements. Agile doesn't mean less documentation — it means right-sized documentation delivered at the right moment."

"I ask three questions: Is the pattern too complex for rules? Do we have enough data to train reliably? Is the cost of errors acceptable given the use case? If rules can solve 90% of cases cleanly and the remaining 10% are low-stakes, rules are probably better. AI shines when the pattern space is genuinely complex, when volume is high enough for statistical learning, and when we have a feedback loop to improve over time."

"I'd first make sure we're measuring the same thing against the same success criteria — which should have been defined at requirements stage. If the model meets the technical metrics but I'm concerned about real-world behavior on edge cases or corner cases the test set doesn't cover, I'd push for an expanded UAT on a broader sample. The technical metric and the business outcome aren't always the same thing — my job is to make sure we're optimising for the right one."

"I use analogies grounded in their domain. Instead of 'the model has 87% precision', I say 'for every 100 recommendations it makes, roughly 13 will be off the mark — here's how we've designed the product to catch and correct those before they reach the customer.' I always pair a limitation with the mitigation design, so stakeholders understand we've planned for the failure mode."

"I use a combination of RICE scoring and Kano categorisation. First I categorise: basic needs get prioritised regardless of score; performance features get ranked by RICE; delighters get time-boxed to innovation capacity. For AI features I add a data readiness gate — a high-RICE feature that lacks labeled training data still can't enter the sprint. I run refinement sessions mid-sprint to ensure the top of the backlog is always sprint-ready. Nothing enters sprint planning without clear AC and no unresolved dependencies."

Use the STAR format. Set up a real scenario: a technical dependency discovered mid-sprint, a model performing below threshold during UAT, a stakeholder changing requirements on Day 4. Describe: how you triaged, what you descoped and why, how you communicated to stakeholders, and what process change you introduced in the retrospective to prevent recurrence. End with what you learned.

"I prevent it upstream rather than managing it mid-sprint. Clear AC, a defined DoD, and a Sprint Goal that everyone has agreed to are my primary defences. When new requests come in mid-sprint, I acknowledge them, log them in the backlog, and explain why adding them now would put the Sprint Goal at risk. The only exception is a critical production issue — and even then I work with the SM to descope something of equivalent size."

"I treat data scientists as full product partners in discovery — not just executors. I involve them early when evaluating whether ML is the right approach. I write model specs (not just functional specs) so they have clear quality targets and evaluation criteria. With engineering, I'm specific about what I need, open about what I don't know, and I never over-specify the 'how'. My job is to describe the problem and the success criteria precisely — their job is to find the best technical path."

"I define success metrics at requirements stage — never after deployment. For automation features: automation rate, confidence threshold distribution, human correction rate. For classification models: precision, recall, F1 calibrated to the cost of each error type. For user-facing features: task completion rate, time-to-resolution, user satisfaction. And I define a monitoring requirement in the DoD: how will we detect drift, what triggers a review, and what is the retraining cadence?"

"I write AC in Given/When/Then format across four scenario types: happy path, edge case, failure case, and non-functional. For AI features specifically I add a fifth: model quality AC — the precision or recall threshold the model must meet on a defined evaluation dataset before the story is accepted. And a sixth: monitoring AC — how will we detect in production if the model's performance degrades. Most teams skip the last two. That's where production AI features break silently."

"It's a product decision rooted in the cost of each error type. I ask: what happens when the model is wrong and we auto-acted? What's the cost of that error versus the cost of routing to human review? I map this on a simple matrix: high-consequence decisions (financial, legal, medical) get conservative thresholds — lower automation, higher human review. Lower-stakes decisions can tolerate higher automation with occasional errors. I review the threshold quarterly as we gather production data."

"First I investigate the gap: is the production input distribution different from the test set? Are there data quality issues in production? Are edge cases that weren't in the test set appearing at high frequency? Then I act based on the severity — if the performance gap is critical, I roll back to a rules-based fallback or increase the human review threshold temporarily. I then work with data science to collect and label production examples and retrain. And I add distribution monitoring to the production observability stack to detect this earlier next time."

"I use business value and user impact as the anchor — not seniority or volume. I map competing requests against the current OKRs and ask: which item moves the needle on an outcome we've committed to? I document the trade-offs and present a clear 'Option A vs Option B' to the decision-maker — with the business case for each, not just a preference. If two items genuinely tie, the one that unblocks more downstream work wins."

"I first understand why requirements are changing — is it new information, evolving business context, or unclear initial discovery? If it's the latter, the root cause is upstream and I fix my discovery process. For mid-sprint changes, I explain the impact transparently: 'Adding this now means descoping X and delaying Y — is that a trade-off you want to make?' Documenting the decision and its rationale creates accountability on both sides and reduces future scope churn."

"I translate technical metrics into business language. Instead of 'the model has 87% precision,' I say 'for every 100 recommendations, roughly 13 will be off-target — here's how we catch and correct those.' I always pair a limitation with the mitigation design. And I set expectations proactively at launch — stakeholders who understand the limitation upfront are partners in improvement; stakeholders who discover it after the fact are complainants."

Use STAR. Pick a real example. The lesson should be about your discovery process, success metric definition, or assumption validation — not about blaming engineering or external factors. Interviewers are looking for intellectual honesty and learning agility.

"I structure the ambiguity first — what do I know, what don't I know, and what's the cheapest way to find out? If I need to make a decision before I can gather data, I make the reversible bet and monitor closely. For irreversible decisions I invest more in upfront research. I document my assumptions explicitly so I can validate them early and course-correct before the cost of being wrong becomes too high."

Pick a specific example where you declined a significant feature request or killed a project mid-stream. The answer should show you defended a principle (product coherence, user trust, technical sustainability) over short-term pressure, communicated the decision respectfully, and offered an alternative path that served the underlying need.

“I treat it as a security requirement, not an afterthought. At the prompt level: explicitly instruct the model to ignore attempts to override its instructions, use structured input formats that separate user content from system instructions, and add injection defence language. At the application level: validate and sanitise all user inputs before they reach the model, implement content filtering on outputs, and log anomalous patterns for review. I include prompt injection test cases in the eval dataset and test every prompt change against them.”

“They solve different problems. RAG is better when you need the model to access specific, up-to-date, or proprietary information at inference time — it grounds the response in retrieved context. Fine-tuning is better when you need the model to behave consistently in a specific style or domain, and the knowledge is stable. I start with RAG because it’s faster to iterate and easier to update. I consider fine-tuning when RAG retrieval quality is the bottleneck or when the model needs to adopt a very specific output format or persona that prompting alone can’t reliably achieve.”

“I start with the as-is process — map every step, measure volume and time, identify where decisions happen and what information drives them. Then I apply three filters: is this high-volume and repetitive? Is the input and output well-structured? What’s the cost of an error? The intersection of high volume, structured data, and tolerable error rate is where AI delivers reliable value. I prioritise the step that creates the biggest downstream wait — not necessarily the one that takes the most process time.”

“I treat adoption as a product requirement, not an afterthought. Three things I do: First, involve the people who do the current process in the design — they surface the edge cases and their buy-in matters. Second, design the AI to assist rather than replace, at least initially — ‘AI suggests, you decide’ builds trust faster than full automation. Third, make the AI’s reasoning visible where possible — when people can see why the model made a recommendation, they trust it more and can correct it when it’s wrong.”

Answer in 3 parts:

Map the landscape early. In discovery, I identify applicable regulatory frameworks — EU AI Act risk tier, GDPR if personal data is involved, and any sector-specific rules (FDA for healthcare, SR 11-7 for finance). I don't wait for legal to flag this. I bring compliance into the conversation at the requirements stage.

Design compliance in, not on. For high-risk systems, that means explainability by default, human override mechanisms, audit logging from day one, and a model card in the technical documentation. These are acceptance criteria — not features to be added later.

Gate the release process. Model validation, privacy impact assessments, and compliance sign-off are milestone gates in my release plan. They're scheduled sprints, not surprises before launch.

Show structured incident thinking:

Immediately: Trigger the human escalation path — which should already exist in the product design. If the failure mode appears systemic, pause automated decisions in that category. Document everything for the audit trail.

Short-term: Root cause analysis with data science — was this a model failure, data drift, an edge case, or a threshold misconfiguration? Scope the blast radius: how many other users were affected?

Systemic fix: Adjust the confidence threshold, retrain or re-evaluate the model, add this case to the evaluation set, and update the model card. Communicate transparently to affected users per your legal obligations.

Use STAR, but lead with the complexity:

Structure: Situation (who was the stakeholder, what was at stake) → Task (what you needed from them, or what they were blocking) → Action (how you approached the relationship — meetings, framing, escalation) → Result (what changed and what you learned).

Strong signals: You identified the real concern (often not the stated concern), you changed your approach based on what motivated them, and you turned a blocker into a collaborator.

Weak signals: You escalated immediately, you worked around them, or you "won" by outranking them. Interviewers want influence, not force.

Demonstrate translation skill:

"I translate model behaviour into business language and consequences. If precision is 87%, I say: 13 in every 100 recommendations will be wrong. Then I immediately answer the follow-up question they haven't asked yet: here's our plan to catch those errors before they reach the customer.

I also set up the conversation upfront — before the executive ever sees the model output, I've aligned them on what good looks like and what the failure modes are. That way the first time they see an error is never a surprise."

Show structured thinking under uncertainty:

"I separate what I can commit to from what I can only direct. I commit to the business outcome and the process — discovery, data readiness, evaluation, staged rollout. I don't commit to a ship date for an AI-dependent feature until the model has cleared its performance gate.

I use a Now/Next/Later format with explicit confidence levels, and I define fallback paths for every model-dependent item — so the roadmap stays credible even if the model takes longer than expected.

The thing I do above all else is agree on the go/no-go criteria with stakeholders before development starts. That removes the subjective pressure at launch time and replaces it with a shared, data-driven decision."

Show you can hold your ground while being collaborative:

"I understand the pressure — a firm date is easier to plan around. But giving a date I can't defend doesn't help either of us.

What I'll do is give you two things: a date by which we'll have a go/no-go decision — that I can commit to firmly — and a range for the ship date conditional on the model hitting its threshold. If the model clears evaluation by sprint 6, we ship in sprint 8. If it doesn't, here's our fallback and the revised timeline.

That way you have a planning anchor and I'm not setting us both up for a missed commitment."