Pushing back when the model is not ready: launch bar, evidence, a safer option

In this article

1. Before you start
2. Why interviewers ask this
3. Pushing back on an unready model from first principles
4. The Staff-level answer
5. The rubric
6. Three variants of this question
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is one question in the behavioral interview guide. For the general answer shape, read how to answer interview questions first.

Why interviewers ask this

Shipping a model before it is ready costs users and teammates, and so does an engineer who stays silent or refuses without offering a path. Candidates report versions of this question at fintech, banking, gaming, cloud-software and AI-lab companies, among the common interview questions for machine learning (ML) roles. The question tests judgement under deadline pressure: whether you can hold a quality line without becoming an obstacle.

A weak answer says the model was bad and the date was unfair. A strong answer shows a measured gap, a calm conversation and a result. A Staff-level answer goes further: it offers a safer alternative with a date and says what you did after the decision.

Pushing back on an unready model from first principles

Launch bar

A launch bar is a written minimum result on a named metric, measured on data the model never trained on, that a model must reach before it ships to users. Ideally, teams set it before the work ends, so the argument is about a number everyone already accepted.

Heuristic baseline

A heuristic baseline is a simple hand-written rule or lookup that solves the same task with no machine learning. It works as a safe first version and as the score a model must beat to justify its extra risk.

In plain words

Think of a structural engineer who finds that the concrete has not cured. The engineer does not shout and does not refuse to work. They tell the client what was measured, offer a later pour date or a temporary support, and then work to the client's choice. The client owns the decision; the engineer owns the evidence and the options. The analogy breaks in two places. A cure time is set by physics, while a model's launch bar is a number your team agreed and can renegotiate. And where real harm to people is at stake, the engineer does not simply go along: you raise it further, as the follow-up on overruling explains.

In one precise sentence, pushing back on an unready model is stating a measured gap against an agreed bar, proposing an alternative, and committing to the final call.

Step 1: Name the launch bar and the gap in the stakeholder's terms

A pushback starts from a number both sides agreed on, the launch bar, not from your feeling about the model. Take an illustrative case: the bar is a precision of 0.90, the model scores 0.82 on the holdout set, and it sends two thousand items a week to manual review.¹

A false positive is an item the model flags that turns out to be fine. At 0.82, about 360 false positives reach reviewers each week; at the bar, 200 would. At six minutes of review each (illustrative), the gap costs 16 extra hours of review every week.¹ Say that sentence to a product lead, not "the precision is low." Input: the metric and the bar. Output: the gap as time, money or risk. You now have a gap the other side can weigh.

Step 2: Show evidence, not opinion

Evidence is a measurement on data the model did not train on, with its uncertainty. Suppose the holdout set holds 500 flagged examples (illustrative). A 95% confidence interval is a range built by a method that, over many repeated samples, captures the true value 95% of the time. Here the interval for a precision of 0.82 on 500 flagged holdout examples runs from about 0.79 to 0.85, so the bar of 0.90 lies well outside it.¹ The gap is not noise.

Readiness is also more than held-out accuracy. Zinkevich's Rule 5 of the Rules of Machine Learning says to make sure the model in your training environment gives the same score as the model in your serving environment. Rule 8 asks how much performance degrades if the model is a day old, a week old or a quarter old. Bring one such check to the conversation. Input: a holdout score and an interval. Output: a gap that survives a challenge.

Step 3: Offer a safer option instead of a flat no

A flat no leaves the stakeholder with a problem and no plan, so a strong pushback arrives with two or three options. The first is a heuristic baseline now and the model later. Google's guidance supports it: Rule 1 is "Don’t be afraid to launch a product without machine learning." The same page says, "If you think that machine learning will give you a 100% boost, then a heuristic will get you 50% of the way there."

In the illustrative case, a stricter rule with a precision of 0.95 flags 1,200 items a week, so it sends 60 false positives to review, against 360 for the model today and 200 at the launch bar. It also catches about 1,140 real cases against the model's 1,640, so its recall is lower and it misses some fraud the model would catch; that is the trade-off the stakeholder chooses, which is why you state it.¹

The second option is a small launch with human review. The third is a dated re-test after a named fix. Give dates: the rule ships in two weeks, and a three-week model fix moves launch from week eight to week eleven.¹

Text description of the diagram

• Illustrative false positives per week are 360 for the model today, 200 at the launch bar and 60 for the rule.
• The rule sends fewer wrong items to review than the model does today.

Step 4: Commit to the decision that is made

Disagree and commit is the habit of stating an objection openly and then putting full effort behind the decision once it is made. Amazon's published principle, "Have Backbone; Disagree and Commit," says leaders are obligated "to respectfully challenge decisions when they disagree." It adds, "Once a decision is determined, they commit wholly." That page covers the behavioral frame only, not machine learning; the Amazon Leadership Principles page explains the full set.

If leadership launches the model anyway, write down the risk and agree the metric that triggers a rollback. If they pick your option, do the same and then make it work. Reported practice differs between companies, and these four steps are our own method. Finish your story with the result.

1 · Name the bar2 · Show evidence3 · Offer an option4 · CommitReplay

Step-by-step description

1. Start from the agreed launch bar and state the gap in the stakeholder's terms.
2. Use a held-out score with its uncertainty.
3. Bring a safer way to ship, not a flat no.
4. Back the decision and agree a rollback trigger.

• A pushback starts from a number both sides agreed on, the launch bar.
• Evidence is a measurement on data the model did not train on, with its uncertainty.
• A flat no leaves the stakeholder with a problem and no plan.
• Write down the risk and agree the metric that triggers a rollback.

The Staff-level answer

The numbers in this sample answer are illustrative and match the steps above. Say it in about a minute.

What makes it Staff-level: it names the bar, prices the gap in the stakeholder's own cost, offers an alternative with a date, states the trade-off, and ends on commitment and a rollback trigger.

The rubric

A strong answer shows these dimensions; the table is a guide for self-review, not any company's scoring sheet.

Three variants of this question

Leadership has unrealistic requirements or delivery timeline. How would you push back?

Ask which part of the date or scope matters most, estimate each piece of the plan, and show what fits by the date. Offer a smaller scope or a later date for the rest, then commit to whichever they choose. The same steps answer "tell me about a time you had to tell leadership their timeline was unrealistic."

Tell me about a time you disagreed with a business stakeholder about a model's readiness.

Use the same four steps. Stress that you translated the metric into their cost and never argued about model architecture, and end with the result.

Tell me about a time you argued that machine learning was the wrong tool for a problem.

Lead with the heuristic baseline: show that a simple rule met the need at lower risk. Google's guidance says a product can launch without machine learning, so you are not arguing against the technology, only for the right first version. If your story is a project you finished but chose not to release, the same bar-and-evidence structure applies; end on what you shipped or changed instead.

Common mistakes

• "This model isn't good enough, so we can't launch." (wrong) It gives no number and no option. (right) "The model is below our bar by this much, and here are two ways to ship safely."
• "They just didn't understand machine learning." (wrong) It blames the other person. (right) "They needed a date, so I tied the metric to a cost and a timeline."
• "It runs in production, so it is ready." (wrong) A silent failure raises no error; Rule 10 describes a table stale for six months, where refreshing it alone raised the install rate by about 2%. (right) "It runs; here is how we check quality and freshness."
• "I escalated again after they decided." (wrong) When the issue is only a disagreement, it undercuts the commitment half of the answer. (right) "I recorded the risk, agreed a rollback trigger and helped the launch succeed."

Follow-up questions

What if the stakeholder overrules you?

Commit, as in step 4: record the risk, agree the metric that triggers a rollback and help the launch succeed. Escalating over their head after the decision is made, for an ordinary disagreement, undercuts the commitment half of the answer. The exception is a risk of real harm to users, a legal or compliance issue, or a safety problem: then say openly that you will raise it with the decision-maker's lead, and do so before launch.

How do you respond when a shipped model underperforms?

Say how you noticed, what you limited (traffic, scope or a rollback) and what you added so it is caught earlier. Rule 10 warns to watch for silent failures, so monitoring and freshness checks are a natural thing to add.

How do you push back without sounding like a blocker?

Arrive with options and numbers, say what you can ship by the date, and ask what matters most to them. For wording, see how to describe your style in interpersonal communication.

What if the model is ready but the data pipeline is not?

Say so, with the same structure. Rule 4 is to keep the first model simple and get the infrastructure right, and Rule 5 says to test the infrastructure independently from the machine learning, so pipeline readiness is a legitimate reason to say not yet.

Why not just raise the threshold?

Raising the decision threshold lifts precision but cuts recall, so the model flags fewer real cases. Check whether recall at a precision of 0.90 still meets the product need; if it does, that is a fourth option, and you can offer it with a date.

Sources

1. Amazon Leadership Principles — Amazon (aboutamazon.com), accessed 2026-10-26, 26 Oct 2026
2. Best Practices for ML Engineering (Rules of Machine Learning), Martin Zinkevich — Google for Developers, accessed 2026-10-26, 26 Oct 2026