The product owner is unreachable and the team needs a rule decided today to ship on Friday. What do you do?

Sort by reversibility before anything else

The instinctive framing is about authority: this is the product owner's decision, so the work waits. That answer is safe and it is also why teams stall, because most of the questions that arrive mid-sprint are not decisions the product owner would want to be woken for.

The useful axis is what reversal costs. A choice about the wording on a validation message can be changed on Monday for the price of a five-minute edit. A choice about whether the rule applies from the date of the application or the date of approval determines what goes into the database, which means Monday's reversal is a data migration and a conversation with anyone who has already seen the wrong figure. The first is yours to make. The second is not, whatever the deadline says.

So the sentence to say in an interview is that you separate decisions by the cost of being wrong, not by the seniority of the person who normally makes them, and that a decision which writes irreversible data or which changes money is one you escalate rather than absorb. Then explain what you do in each case, because the interviewer is grading the mechanism rather than the principle.

Look for the answer before treating it as open

A surprising proportion of these questions have already been answered somewhere and nobody looked. Before deciding anything, spend twenty minutes on four sources.

The first is the existing system, if there is one, because how it currently behaves is very often the rule; a replacement that quietly changes it is a change nobody asked for. The second is written policy: an operations manual, a regulatory obligation, a published terms-of-service page, a rate card. The third is the decision log from earlier in the project, where the same question has frequently been asked in a slightly different form. The fourth is anyone else who does the work — a team leader, a support agent, a trainer — who is not the product owner but who knows the answer and whose confirmation you can quote.

Finding the rule in a source turns the question from a decision into a fact, and a fact needs nobody's approval. This step is what distinguishes an analyst from a coordinator, and it is skipped almost every time.

Build the option that keeps both answers alive

Where the rule is genuinely open, ask whether the build has to commit to it. Often it does not, and the cheapest thing to do is to defer the decision rather than to make it.

A worked example. The question is whether part-month joiners are charged a full month or a pro-rata amount. Hard-coding either answer takes half a day. Putting the proportion behind a configuration value takes a day, and the extra half-day buys the ability to change the answer on Monday with a configuration change rather than a release. If the release cadence is fortnightly, that half-day is the difference between correcting the rule on Monday and correcting it in three weeks. Say those numbers out loud when you propose it, because the argument is arithmetic rather than preference, and a developer will accept it on those terms and reject it as a matter of principle.

The same logic applies to the data. Where the decision is about a value, storing both the raw inputs and the computed result keeps the recomputation available; storing only the result does not. That is the kind of contribution that makes a business analyst useful in a technical refinement conversation, and it does not require you to write any code.

Record it as an assumption with a deadline

If you do decide, the decision is worthless as a memory and dangerous as an undocumented one. It needs to be written where the team and the product owner both look, and it needs four things: what was assumed, why, who is affected if it is wrong, and by when it must be confirmed.

Something like this, posted in the team channel and attached to the story:

Assumption A-14, 29 July. Part-month joiners will be charged pro-rata to the day, because that is what the legacy system does and what the published price list implies. Decided by me in the product owner's absence; the alternative is a full month's charge. If this is wrong, roughly forty accounts a month are billed incorrectly and the correction is a rebilling exercise rather than a code change. Confirmation needed from Priya by 2 August, before the first billing run on the 5th.

That paragraph does the work of an escalation without being one. It names the decider, so nobody discovers in October that a rule appeared from nowhere. It states the exposure in business terms, which is what makes a product owner read it rather than skim it. And the deadline is tied to a real event rather than to a general sense of urgency, which is why it gets answered.

The forty accounts in that example is an illustration; the point is that a number belongs there, because "if this is wrong we will need to fix it" produces no urgency and "forty accounts and a rebilling exercise" produces some.

What quietly turns into permanent policy

The failure that does the damage is not making the wrong call on Friday. It is that a decision made under time pressure is never revisited, because on Monday the thing works, the sprint has moved on, and nobody has an incentive to reopen a question that appears closed. Six months later the pro-rata rule is how the business operates, and nobody in the room chose it.

Which is why the assumption log only functions if something forces it to be read. Take open assumptions to sprint review as a standing item, keep the list short enough that reading it aloud takes two minutes, and close each entry explicitly rather than by silence. An analyst who can say at review that three assumptions were made this sprint, two are now confirmed and one is still open and expires on Tuesday, is doing the part of the job that has no visible output and prevents most of the arguments.

The other half of the discipline is knowing when the answer is to stop. If the decision changes money, creates a regulatory obligation, cannot be reversed without a migration, or affects an external party who will act on it, then shipping on Friday is not worth it, and saying so is the more senior answer. Stopping a release costs a day of visible embarrassment. An irreversible wrong rule costs a quarter of invisible remediation, and the reason candidates get this wrong is that only the first cost has anyone's name on it.

Decide by the cost of reversal, not by rank. Where you must decide, build the version that can be changed on Monday, write the assumption down with an owner and a date, and make sure something in the team's routine forces it to be read.