Frameworks

The go-to structure for "design a product for X" questions.

CIRCLES stands for comprehend the situation, identify the customer, report their needs, cut through prioritization, list solutions, evaluate trade-offs, and summarize your recommendation. It comes from the book Decode and Conquer, and interviewers use design questions specifically to see whether you naturally structure an open-ended problem instead of jumping straight to a solution.

Study it by practicing the sequence out loud until it feels automatic, then deliberately vary the pacing, since spending too long clarifying or too long brainstorming both read as weaknesses. The most common failure isn't forgetting a step, it's rushing to solutions before the customer and their need are clear.

Use it to brainstorm broadly, then commit to one metric.

AARM organizes metrics around the user journey: acquisition, activation, retention, and monetization. It's a brainstorming tool, not the final answer, so the real skill it tests is whether you can generate several reasonable metrics and then defend picking just one as a north star.

For diagnosis questions, like "a metric dropped, why," pair AARM with an issue tree: is the drop real, what are the possible causes, and how would you segment the data to narrow it down. Interviewers are listening for structured elimination, not a lucky guess at the cause.

State every assumption out loud, even the obvious ones.

Estimation questions test comfort with ambiguity and basic quantitative reasoning, not your ability to recall real numbers. Decide whether to go top-down, starting from a large population and narrowing down, or bottom-up, building from a small unit and scaling up, and say which one you're choosing and why.

Round numbers aggressively to keep the math clean, state each assumption as you use it, and finish with a sanity check against something you actually know, like store counts or population figures. Always name the one or two assumptions that would move the answer the most, since that shows judgment about what matters.

For "should company X enter market Y" questions.

This checklist evaluates three things: the market itself, meaning its size, growth, margins, and trends, the competitive environment, meaning who's already there and how defensible their position is, and company fit, meaning whether the company's existing strengths and assets actually help here.

The most common mistake is skipping company fit and only evaluating whether the market is attractive in the abstract. A market can be huge and growing and still be a bad idea for a specific company if it doesn't build on anything that company is already good at.

Score, then check the score against strategy.

RICE scores an initiative as reach times impact times confidence, divided by effort. It gives prioritization questions a quantitative backbone instead of a purely qualitative debate.

The part candidates most often skip is the step after scoring: checking the highest-scoring option against strategic goals, dependencies, and risk. A framework score is an input to the decision, not the decision itself, and saying that explicitly is what separates a mechanical answer from a judgment-driven one.

Dramatize, indicate alternatives, go through what you did, summarize impact.

DIGS is a structure for behavioral answers: dramatize the situation so the stakes are clear, indicate the alternatives you considered so the interviewer sees you weren't on autopilot, go through what you actually did, and summarize the impact with a number if you can.

It's close to the more widely known STAR method, situation, task, action, result, with one addition: explicitly naming alternatives you didn't take. That's the part worth rehearsing, since it's what shows judgment rather than just narrating events in order.

Google's own framework for measuring user experience quality.

HEART measures happiness, engagement, adoption, retention, and task success. It was developed at Google specifically to give UX and product teams a shared vocabulary for quality metrics beyond raw usage counts, so it's worth knowing by name in a Google interview.

Use it when a question asks you to evaluate the quality of an experience, not just whether people use it. Task success in particular is the metric most candidates forget: it measures whether people actually accomplished what they came to do, which usage numbers alone can't tell you.

The one number a whole team rallies around.

A north star metric is the single measure a team optimizes for because it best captures the value the product delivers to users, in a way that's expected to also drive business results if it improves.

A good north star reflects real value delivered, not just activity, is measurable in the near term, and is something the team can actually influence. When asked for "the one metric that matters," interviewers want to see you reject vanity metrics like raw signups or pageviews in favor of something that ties usage to value.

Reframe the question around the job the customer is "hiring" the product to do.

Jobs to Be Done reframes a product around the underlying job a customer is trying to get done, rather than the product category itself. The classic example is that people don't want a drill, they want a hole in the wall, and really they want the shelf that hole makes possible.

It's useful for design and strategy questions where the obvious framing is too narrow. Naming the real job a customer is hiring the product for often reveals competitors you wouldn't otherwise consider, since anything that gets the same job done is a competitor, even if it looks nothing like your product.

Sort features into basic, performance, and delight.

The Kano model classifies features into three types: basic features that cause dissatisfaction if missing but don't create much delight when present, performance features where more is simply better, and delight features that create disproportionate satisfaction because they're unexpected.

It's a good addition to a prioritization answer because it adds a dimension RICE doesn't capture well: not all high-impact features behave the same way as you invest more in them. Knowing which category a feature falls into changes whether it's worth over-investing in it.

Strengths, weaknesses, opportunities, threats.

SWOT separates internal factors, strengths and weaknesses, from external factors, opportunities and threats. It's a simple structure for strategy questions that ask you to evaluate a company's or product's position before recommending a direction.

Used well, it's a quick scan, not the whole answer: the real value comes from what you recommend after the scan, connecting a specific strength to a specific opportunity, rather than just listing four boxes of observations and stopping there.

How companies like Google translate strategy into measurable goals.

An objective is a qualitative, ambitious statement of what you want to achieve. Key results are the specific, measurable outcomes that tell you whether you got there. Good key results are outcomes, not tasks, meaning "increase task success rate to 90 percent," not "ship feature X."

This is worth knowing cold for a Google interview specifically, since OKRs are how the company sets and communicates goals internally. If a question asks how you'd set goals for a team or a quarter, framing your answer as an objective with two or three measurable key results shows fluency with how the company actually operates.

A funnel-shaped cousin of AARM: acquisition, activation, retention, referral, revenue.

AARRR walks through the same early stages as AARM but adds referral as its own stage and treats the whole thing as a strict funnel: acquisition, activation, retention, referral, revenue. It's useful when a question is specifically about growth, since it forces you to consider how existing users bring in new ones, which AARM doesn't call out separately.

Knowing both frameworks and the difference between them is more useful than memorizing either one alone: AARM is a broader lens for organizing any product's metrics, while AARRR is sharper for questions specifically about a growth funnel.

A fast, visual way to sort ideas into four quadrants.

This plots initiatives on two axes, impact and effort, creating four quadrants: quick wins, which are high impact and low effort, big bets, which are high impact and high effort, fill-ins, which are low impact and low effort, and time sinks, which are low impact and high effort.

It's a faster, more visual alternative to RICE when a question just wants a quick prioritization pass across many small ideas rather than a precise ranking of a few. Naming which quadrant something falls into is a quick way to justify deprioritizing an idea without a lot of math.

Ask "why" repeatedly to get from a symptom to a root cause.

Five Whys is a simple root-cause technique: state the problem, ask why it happened, then ask why that answer happened, repeating roughly five times until you reach a cause that's actually actionable, rather than stopping at the first, most visible explanation.

It's a good tool to name explicitly in diagnostic questions, like a metric that dropped, because it signals that you won't stop investigating at the first plausible-sounding explanation. The discipline of it is refusing to recommend a fix until you've pushed past the surface-level symptom.

Write the press release before you build the product.

Working backwards starts by writing the press release and FAQ for a product as if it already shipped, describing the customer benefit in plain language before any design or engineering work happens. If the press release doesn't sound compelling on its own, that's a signal the idea isn't strong enough yet.

Even outside companies that use this formally, it's a useful mental model for vision and product-design questions: if you can't describe the customer benefit in two plain sentences a real person would care about, the idea needs more work before you pitch a roadmap around it.