How to show product judgment, not just activity

Find a moment when you had to choose

Start with a decision where there was more than one reasonable option.

Maybe you had to choose between fixing an existing workflow and building a requested feature. Perhaps customer research challenged something already on the roadmap. Or an engineering estimate forced you to reconsider the scope.

You don’t need a company-changing decision. Choose one where you can explain what made the answer unclear at the time.

For example, “I prioritized the import fix” leaves out most of the story. What else was competing for the team’s time? Who needed the fix? Why couldn’t it wait?

Explain what led you to the decision

Here’s an illustrative starting point:

“I reviewed customer feedback and prioritized improvements to the import flow.”

That tells someone what you did. A fuller explanation shows the reasoning:

“We were choosing between a dashboard sales wanted for demos and fixes to our data import flow. I reviewed support conversations and joined calls with customers who hadn’t completed setup. Import errors were preventing some of them from getting their data into the product, so they couldn’t start using it.

“I recommended fixing the import problems first. The dashboard could help us explain the product to prospects, but the import issues were blocking customers who were already trying to use it.”

The recommendation is easier to understand because the speaker connects what they learned to the choice they made.

Use the information you actually had. That might include usage data, customer conversations, support requests, technical constraints, or a deadline you couldn’t move.

Give the other option a fair explanation

A decision sounds less convincing if you make the alternative seem obviously foolish.

In the example, sales had a legitimate reason to want the dashboard. It could make demos more useful. Delaying it had a cost.

You could explain that part like this:

“The sales lead was concerned about upcoming demos, so I asked which parts of the dashboard they needed most. We agreed they could use a manual report temporarily, though that created extra work for them. I brought that cost into the planning discussion when I recommended doing the import fix first.”

This gives the interviewer something meaningful to explore. How much extra work was acceptable? What if the manual report hadn’t been possible? What would have changed your recommendation?

Describe the actual conversation and compromise from your own experience. You don’t need every decision to end with everyone getting what they wanted.

Say what you still needed to learn

You probably didn’t know everything when you made the decision. Include an uncertainty if it affected your approach.

For example:

“Most of the complaints came from customers uploading large files. We didn’t yet know whether smaller accounts were running into the same issue, so we included both groups in the rollout checks.”

Then explain how you followed up. What did you look at after the change? Did the result support your reasoning, or did you need to adjust?

If the work was still underway when you left the project, say what you planned to check. Keep that separate from results you actually observed.

Add the reasoning to one of your answers

Take a draft that lists what you did. Find the most important decision and complete these sentences:

• “We could have…”
• “I recommended…”
• “What led me to that choice was…”
• “That meant accepting…”
• “Afterward, we checked…”

You don’t have to use those exact phrases in the interview. They’re prompts to help you find the details worth explaining.

Read the answer again. Could someone understand why your choice made sense at the time—even if they might have chosen differently?

If your ending still stops at “we shipped it,” use this guide to explaining outcomes. You can then bring the decision, reasoning, and result together in your Remi answer.