"A competitor just launched your core feature for free. What do you do?"
Weak: match the price.
Stronger: first find out who is actually switching. If it's your low-value users, letting them go may be fine. If it's your best accounts, the problem is bigger than price.
Diagnose before you react.
Your org chart ships products.
If payments and checkout sit in different teams with different targets, the handover between them is exactly where your users get frustrated.
Plenty of UX problems are reporting-line problems in disguise.
Averages hide the users you most need to see.
Average session time is up 10%. But it might be power users staying longer while new users leave faster.
Split every headline metric by new versus returning users and by platform before you celebrate it.
"Design a product for people who forget to drink water."
Most candidates jump straight to a reminder app.
Stronger: first ask who forgets and why. An office worker in back-to-back meetings and a 70-year-old on medication need completely different products.
The segment you pick decides the answer.
Use RICE to start a prioritisation discussion, not to end it.
Its real value is forcing everyone to write down assumptions. Reach of 50,000 users, based on what?
When the sales head and the engineering lead score the same item very differently, you've found the conversation worth having.
More process often signals less trust, not more maturity.
When every launch needs four approvals, it's usually because one bad launch years ago was never properly understood.
Fix the original failure and you can remove the three approvals it created.
"How many cups of chai are sold in Bengaluru every day?"
Pick your structure out loud: supply side (tea stalls × cups per stall) or demand side (people × cups per person).
Then do both quickly. When two methods land close together, your number becomes believable.
Consensus is a poor goal for product decisions.
Getting everyone to agree usually means choosing the option nobody strongly objects to, which is often the weakest one.
Aim for a decision people understand and can commit to, even if some of them disagree.
Silence while you think is fine. Silence for a full minute isn't.
If you need time, say what you're weighing: "I'm deciding whether to focus on new users or existing ones."
An interviewer can't score thinking they can't hear.
Listen to sales and support call recordings for an hour every week.
You'll hear what customers never write in surveys: their exact words, where they hesitate, what they compare you with, and the objection that actually stalls the deal.
It's the cheapest research most teams already have and never open.
"DAU dropped 15% week on week. What do you do?"
Before any hypothesis, check whether the drop is real: a tracking change, a new app release, a holiday, or one platform only.
On the job, a large share of scary drops turn out to be measurement problems.
Checking this first makes you sound like you've done the job.
"What's the North Star metric for a food delivery app?"
"Orders" is the easy answer. But a coupon order that never repeats isn't value.
Something like "orders from customers who also ordered in the previous 30 days" captures repeat value.
Explain what your metric deliberately ignores.
"Driver cancellations spiked in one city. Fix it."
First find out when and where. If it's peak hours to certain areas, drivers may be avoiding empty return trips.
The fix might be pricing or destination incentives, not a new screen.
Not every product problem has a UI solution.
Junior PMs are judged on what they ship. Senior PMs, increasingly, on what they decide not to ship.
Moving up makes your biggest contributions invisible: the project you stopped, the hire you made, the argument you settled early.
That's why senior impact is so hard to put on a CV.
2023: "Can we add a chatbot?"
2024: "Can we add AI to the chatbot?"
2025: "Can we turn the AI into an agent?"
2026: "Customers keep asking for a phone number they can call."
No hard number for your project? Use this order:
1. The real measured number.
2. Non-numeric evidence it worked: fewer escalations, user feedback, a stakeholder's decision.
3. An honest estimate, labelled as one.
Never invent a number. The follow-ups will find it.
Write the edge cases before engineering has to ask.
What happens when the payment fails halfway? When a user has two accounts? When the network drops mid-upload?
Edge cases found in QA cost days. Edge cases written in the PRD cost minutes.