How to Prioritize Without Falling Back on a Vague 'It Depends'

The problem

There is a kind of interview question a lot of people answer on autopilot:

“How do you prioritize?”

And then comes the classic escape:

“It depends.”

Technically, that is usually true.

But as an answer, it is usually weak.

Because it does not help you distinguish between:

• someone who really thinks about priority
• and someone who only learned how to hide behind ambiguity

The problem is not recognizing context.

The problem is using context as an excuse not to choose anything.

Mental model

Think about it this way:

prioritization is deciding what needs to be protected first when not everything can fit at the same time.

That definition already improves the conversation.

Because it moves prioritization away from preference and into protection.

You start asking questions like:

• what hurts most if it slips?
• what is irreversible or expensive if it goes wrong?
• what unlocks the most value now?
• what can wait without turning into a real problem?

That is very different from just listing nice-sounding criteria.

Breaking the problem down

”It depends” only works if structure comes next

Saying that it depends is not the mistake.

Stopping there is.

If you use it depends, you need to follow it with something like:

• it depends on the main goal right now
• it depends on how big the impact is
• it depends on the risk of pushing it back
• it depends on who is blocked or exposed

In other words: the problem is not admitting variables.

The problem is failing to organize them.

Not every urgent thing deserves the top slot

This is a very common team mistake.

Something shows up looking urgent, and the whole queue bends around it.

But apparent urgency can just be:

• pressure from the requester
• local discomfort
• operational anxiety
• lack of planning clarity

Mature prioritization separates:

• perceived urgency
• from real impact

Sometimes the loudest thing is not the most important one.

Value without risk can also mislead you

The opposite trap exists too.

Something may look high-value, but it might require:

• too much effort
• maturity the team does not have yet
• a structural change that is too big right now
• operational risk the company cannot afford

At that point, prioritization is not just about maximizing gross value.

It is about balancing value with feasibility, risk, and timing.

Good prioritization makes the cost of delay explicit

When someone prioritizes well, it does not look like they chose one isolated item.

It looks like they chose an order and accepted a cost.

That usually sounds like:

• “We should attack this now and accept that other risk for two more weeks.”
• “The gain here is bigger, so this refactor waits.”
• “We cannot fit everything, so we protect the main flow first.”

That clarity builds trust.

Because it shows the decision was not accidental omission.

It was a conscious choice.

The best priority criteria changes with the stage

This matters a lot.

In one context, the top priority may be:

• capturing a business window

In another:

• reducing incident risk

In another:

• unlocking future team capacity

That is why mature prioritization is not a fixed formula.

But it is also not pure improvisation.

It depends on the stage, the pressure, and the goal.

Prioritization without cuts is not prioritization

It is worth being direct here.

If everything is a priority, nothing got prioritized.

A strong interview answer usually makes clear:

• what made the cut
• what did not
• why it was left out
• and what risk was accepted

If that does not show up, the answer usually sounds theoretical.

Simple example

Imagine the team has all of these at once:

• an intermittent bug in checkout
• a visual improvement requested by marketing
• a refactor in a hard-to-maintain module

Weak answer:

“I would look at all the context and see with the team what the best priority is, because it depends a lot.”

That says almost nothing.

Better answer:

“My first question would be what threatens the result most right now. If the checkout bug is affecting conversion or user trust, it moves to the top because it hits the main flow and becomes more expensive if we let it sit. The visual improvement may have value, but it would not go before that. The refactor may be important, but I would only pull it up if it were tied directly to the current risk or if the cost of delaying it were about to explode. In other words: I do not order by request volume or by technical taste. I order by business impact, the risk of letting it continue, and the cost of fixing it later.”

That answer shows:

• criteria
• order
• cuts
• explicit cost

Common mistakes

• Using it depends to escape the decision.
• Confusing urgency with real priority.
• Prioritizing the loudest request.
• Talking about value without considering risk and feasibility.
• Not making it clear what was left out.

How a senior thinks

People who have matured usually think like this:

“If I cannot explain what will be left for later, I have not really prioritized yet.”

That sentence helps a lot.

Because it forces you to accept that prioritization always creates discomfort somewhere.

And that discomfort needs to be conscious.

When you can name:

• what you protected
• what you delayed
• why that order makes sense now

your answer immediately has more weight.

What the interviewer wants to see

They want to see whether you:

• can move past abstraction and order things for real
• separate real impact from apparent pressure
• connect priority to business, risk, and timing
• accept trade-offs instead of promising that everything fits
• communicate the reasoning clearly

A strong answer can sound like this:

“When I talk about priority, I try not to hide behind a vague ‘it depends.’ I use context to order things, not to avoid choosing. I usually start from what threatens the result most right now, what it costs to get wrong or delay, and what truly unlocks value in the moment. If I cannot say what I am leaving for later, then I have not finished prioritizing.”

Good prioritization is not a perfect formula. It is being able to order things clearly in imperfect conditions.

When you replace it depends with criteria, the answer stops sounding slippery and starts sounding senior.