🌏 中文版
Today's Focus
Product Sense interviews don't just test whether you have good ideas — they more often test what you do when engineering bandwidth is limited and you have to pick. These questions deliberately hand you a list of features that all sound reasonable, precisely to see whether you'll try to build everything at once, or whether you can first pin down who needs what most, then rank the options against a consistent standard.
This matters because in real product work, resources are never enough. How well you prioritize directly determines whether your team's output actually lands on what users need. Interviewers aren't grading which feature you picked — they're grading whether you can explain the ordering clearly enough that every stakeholder in the room understands it, and clearly enough that it can be challenged.
Framework Cheat Sheet
CIRCLES
When you get an open-ended "help me prioritize / plan X" question, run it through six steps before you let gut instinct take over:
| Step | Meaning | What to do in the interview |
|---|---|---|
| Comprehend | Understand the situation | Ask about the product's current state, the team's resource constraints, and the boundaries of the question itself |
| Identify | Pin down the users | Which users does each feature serve? Who's the priority audience right now? |
| Report | Surface the need | Where are these users currently stuck? Which unmet need carries the highest risk of churn? |
| Cut | List the options | Map the given features to the needs you just identified |
| Ladder | Rank them | Use a consistent scoring standard (RICE, below) to order the list |
| Evaluate | Converge | State which one ships first, and how you'll measure whether it worked |
How to use it live: the "L" (Ladder) step is the one candidates skip most often, defaulting to a gut-feel order instead. That's exactly where the gap between candidates shows up — whether you have a ranking logic you can lay out on the table and defend under follow-up questions.
RICE Scoring
When a question explicitly asks you to rank rather than design, RICE turns CIRCLES's "Ladder" step into four concrete questions you can answer one at a time:
| Factor | The question it answers | How to score it |
|---|---|---|
| Reach | How many users will this touch in a given period? | Use a concrete number or percentage, not "a lot of people" |
| Impact | How much does it change the experience for each user it touches? | Common scale: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal |
| Confidence | How sure are you about the first two estimates? | 100% = backed by data, 80% = medium-high confidence, 50% = an informed guess |
| Effort | How much engineering and design cost does it take? | Estimate in person-months or sprints |
RICE score = (Reach × Impact × Confidence) ÷ Effort. Higher scores rank first — but always add one line in the interview: a RICE score is a tool for converging a discussion, not an unbreakable rule. If a low-scoring item has a strategic reason to move up (a compliance requirement, a competitive differentiator), you need to be able to say why you'd override the ranking anyway.
Today's Practice Question
The Question
"A social app for teens is gaining traction, but engineering bandwidth is limited. As the PM, prioritize these potential features: stories, events, profiles, messaging, and analytics."
(Source: a product management case study collection, theproductfolks.com)
How to Break It Down
- Clarify the problem: Ask the interviewer — is this a brand-new product or the next phase of an existing one? How tight is "limited bandwidth," specifically — one feature per sprint, or two per quarter? What's the current acquisition channel for teen users (school social networks, friend invites, migration from another platform)?
- Define the users: Split teen users into at least two situations — the core user who already has a friend group on the app and opens it daily to check updates, versus the new user who was just invited by a friend and is still deciding whether to stick around. These two groups have very different urgency around each of the five features.
- Structure the analysis: For every feature, ask which group it serves and which need it addresses — content discovery, relationship-building, or self-expression. A profile mostly helps a new user establish an initial identity; messaging and stories mostly give core users a daily reason to come back; analytics mostly serves the internal team, not the end user; events depend on whether the product already has a "group" concept for users to attach to.
- Propose the ranking: Score each feature with RICE — messaging and stories usually have high Reach (almost every user touches them) and high Impact (they directly drive daily return visits), but Effort isn't trivial either. Profile has low Effort and moderate Impact, making it a good low-cost item to ship early. Analytics has Reach close to zero for the end user, so it should rank last — or sit outside this round of prioritization entirely.
- Define success: Don't stop at "ship messaging first" — say what metric you expect to move within a few weeks. For messaging, that's "percentage of users who sent at least one message" and "next-week return rate," not a vague total-user count. Also state when you'd interrupt the ranking to jump analytics to the front — for example, if the operations team has zero visibility into churn signals, which undermines the data behind every ranking decision that follows.
Sample Answer (how to actually say it in an interview)
Clarifying the problem and framing: "I'd first confirm how tight 'limited bandwidth' actually is — one feature a sprint, or two a quarter. Then I'd split users into two groups: the core user who already has friends on the app and checks it daily, versus the new user who was just invited and is still on the fence. These five features carry completely different urgency for each group, so I can't rank them against a single standard."
Structured analysis and ranking: "Once I've got the context, I go feature by feature and ask who it mainly serves and what need it addresses, then score each with RICE. Messaging and stories both score high on Reach and Impact, because they're what decides whether someone opens the app again tomorrow — I'd rank those first. Profile has low Effort and meaningfully improves whether a new user sticks around, so it's a good low-cost item to ship early. Analytics has close to zero direct value for the teen end user — Reach is basically zero — so I'd put it last in this round, unless the operations team is already blocked on making decisions without that data."
Defining success: "I wouldn't stop at 'ship messaging first.' I'd say exactly what I expect to change afterward — I'd watch 'percentage of users who sent at least one message' and 'next-week return rate.' If neither number moves within two weeks, that tells me my Impact estimate was wrong, and the RICE score needs to be re-run — not that I should stubbornly stick to the original order."
Self-Check
Use this table to check whether your answer hit the key points:
| Checkpoint | Covered? |
|---|---|
| Asked how tight the resource constraint actually is, instead of assuming a number | |
| Split users into at least two situations, with needs discussed separately | |
| Ranked using a consistent standard (like RICE), not gut feel | |
| Each ranked feature maps to a specific need you identified | |
| Defined which metric should move after each feature ships, not just "it shipped" | |
| Bonus: named the condition under which you'd break the planned order |
Today's Case Study
Intercom: RICE was invented because the loudest voice kept winning
In January 2018, Intercom product manager Sean McBride published "RICE: Simple prioritization for product managers" on the company's own blog. The problem that prompted it: Intercom's product team kept running into roadmap ideas that were hard to compare directly — some reached every user but had shallow impact, others reached a small group but mattered deeply to them. Without a consistent basis for comparison, these debates tended to end with whoever argued loudest or held their position most stubbornly winning, regardless of which idea actually mattered most. McBride and his colleagues built a scoring system from first principles, testing several approaches before converging on four factors — Reach, Impact, Confidence, Effort — multiplied and divided into a single score that let ideas that were previously impossible to compare sit side by side on the same table.
Interview angle: this case is a direct demonstration of replacing gut-feel ranking with a consistent standard — Intercom was facing exactly the situation in today's practice question: limited engineering resources and features that are genuinely hard to compare. For any feature-ranking question, you can cite this origin story to explain why you need a reusable scoring method instead of re-litigating the order from scratch every time.
Further Reading
- Product Manager Case Study Questions Explained — source of today's practice question; also covers Opportunity Assessment, MECE, RICE, and AARRR as common case-study frameworks
- Product Sense Interview Prep (2026 Guide) — Aced's (formerly Exponent) full walkthrough of the Product Sense interview round and common follow-up patterns
- RICE: Simple prioritization for product managers — the original source of the RICE framework, and the primary source for today's case study
References
- Product Manager Case Study Questions Explained — source of today's practice question about ranking features for a teen social app
- RICE: Simple prioritization for product managers — full context and original definition behind Intercom's 2018 invention of RICE, referenced in today's case study
- RICE Prioritization: Framework, Formula & Template (2026) — explains how each of the four RICE factors is scored, referenced in the Framework Cheat Sheet
Loading...