What "Product Sense" Actually Is — And How Interviewers Test For It

Post 01 of XX

I once watched a candidate flame out of a final-round loop because she had, by every measure, too much product sense. She knew the space cold. She’d shipped real things. But when the interviewer asked her to design a savings feature for gig workers, she jumped straight to a solution — round-ups into a high-yield account — and spent thirty minutes polishing it. Beautiful answer. Wrong answer. She never told us why gig workers struggle to save in the first place, or which gig worker she meant, or what she’d have to believe for round-ups to be the right call. We didn’t learn how she thinks. We only learned what she’d already decided.

That’s the thing nobody tells you about product sense: it’s not knowledge. It’s a way of reasoning out loud that you either expose or hide. And the whole interview is engineered to make you expose it.

So let me try to define the term properly, because most people use it as a vibe.

A definition that actually holds up

Product sense is the ability to reliably figure out what to build, for whom, and why — under uncertainty, with incomplete information, before the data exists. It’s the muscle that lets you look at a fuzzy situation and form a defensible point of view about what matters.

Notice what’s not in there. It’s not taste, although taste helps. It’s not knowing the latest frameworks. It’s not having used a thousand apps. Those things correlate with product sense the way owning a lot of cookbooks correlates with being a good cook. Related, sure. Not the same skill.

The reason fintech makes this sharper is that the cost of being wrong is concrete. If your social app ships a bad feed change, people scroll less. If your money app ships a bad transfer flow, someone’s rent is late, or worse, someone loses funds. Product sense in fintech carries a weight that forces you to reason about consequences, not just engagement. That weight is exactly what good interviewers are probing for.

What’s really being tested

When an interviewer asks a product-sense question, they are not collecting your idea. They could brainstorm features all day without you. They’re running a simulation: if I drop this person into ambiguity, what’s the quality of their thinking? Specifically, four things:

The first is problem framing — do you reach for the problem before the solution, or do you sprint to features? The candidate I mentioned failed here.

The second is user specificity — can you name a real person with a real situation, or do you hide behind “users”? “Users want to save more” is a non-statement. “A 26-year-old DoorDash driver whose income swings 40% week to week and who’s never had more than $300 in savings” is a person I can design for.

The third is prioritization under constraint — when you can’t do everything, what do you do first, and can you defend the cut? Anyone can list ten ideas. The signal is in what you’d kill.

The fourth is judgment about consequences — do you see the second-order effects? In fintech this is the whole game. A “save your spare change” feature sounds harmless until you realize you might be pulling $4 out of an account that’s about to bounce a $35 overdraft.

If you can demonstrate those four, you’ll pass almost any product-sense interview, even with a “wrong” idea. If you can’t, the slickest idea in the world won’t save you.

A simple structure that keeps you honest

I don’t love rigid frameworks, because they make people sound like a podcast. But early in your career a scaffold helps, so here’s the one I’d internalize and then forget:

Goal → User → Problem → Solutions → Tradeoffs → Metric.

You start by clarifying the goal (whose goal — the company’s? the user’s? are they aligned?). You pick a specific user. You articulate the problem they feel, not the one your company feels. You generate a few solution directions — at least two, so it’s clear you chose rather than defaulted. You name the tradeoffs of your pick. And you close with how you’d know if it worked.

The magic isn’t the order. It’s that each step forces a small act of discipline. Picking one user means rejecting others, out loud. Naming tradeoffs means admitting your idea has a downside. That honesty is the texture of real product sense.

A fintech example, start to finish

Say the prompt is “design a feature to help people pay down credit card debt.” Here’s the thinking, compressed.

Goal: the company probably wants engagement and the halo of being “good for customers”; the user wants to feel less crushed by a balance that won’t move. Those can align if I’m careful, but they can also diverge — a debt product that makes money on the debt is a conflict I should name.

User: I’ll pick someone carrying about $6,000 across two cards, making minimum payments, who logs in mostly to check they’re not overdrawn. Not the person with $40k in distress (different product, probably needs a human) and not the person who pays in full every month (doesn’t have this problem).

Problem: minimum payments feel responsible but are a trap — most of the payment is interest, the balance barely moves, and the person has no felt sense of progress. The pain isn’t only financial. It’s the demoralization of running in place.

Solutions: (a) a payoff projection that shows “pay $40 more and you’re debt-free 14 months sooner,” (b) an automatic round-up-to-the-card feature, (c) a debt-snowball planner that orders their cards. I’d lead with (a), because the core problem is the invisibility of progress, and a projection makes progress visible at near-zero risk.

Tradeoffs: a projection can also scare someone into freezing, and if I make the “pay more” nudge too aggressive I might push someone to overpay a card while underfunding rent. So I’d cap suggestions at a fraction of free cash flow and never nudge below the balance buffer.

Metric: I’d watch the share of users paying above the minimum, but my guardrail is overdraft rate — if debt paydown goes up while overdrafts spike, I’ve moved money from one fire to another and made things worse.

That whole answer takes four minutes and never once claims certainty. That’s product sense. Not the round-up idea — the reasoning around it.

Why this matters

Here’s the part the interview prep never mentions: this exact muscle is what you use in the job, constantly, mostly in low-stakes moments that compound. An engineer asks “should the error message say X or Y?” A designer asks “do we really need this screen?” A stakeholder says “can we just add a toggle?” Each of those is a tiny product-sense question, and the PMs who answer them well — quickly naming the user, the problem, and the tradeoff — are the ones who, a year later, seem to have great judgment. They don’t have a god gift. They have a habit.

So the practice isn’t really for the interview. The interview is just the one day someone watches you do the thing you should be doing every day anyway.

Try this before reading next post

Pick any product you used today — your bank app, a payments button, a budgeting tool. In writing, no more than half a page, answer: who is the one user this was clearly built for, what problem does it solve for them, and what’s the most obvious group it ignores? Then ask whether ignoring that group was a smart cut or a lazy one. If you can do that crisply in half a page, you have more product sense than you think. If you can’t, you just found the exact muscle to train this year.

Next post: the “design a product for X” question, and the trap of answering the question they literally asked instead of the one they meant.