CIRCLES framework: full worked example for PM interviews

CIRCLES is the dominant structure for product-design questions at Google, Meta, Amazon, and Airbnb. Lewis C. Lin introduced it in “Decode and Conquer” (2013). The acronym: Comprehend the situation, Identify the customer, Report customer needs, Cut via prioritization, List solutions, Evaluate tradeoffs, Summarize. Product design questions account for 30 to 40% of PM loops at major companies, and CIRCLES is still the expected skeleton in 2026. What has shifted is where the weight goes inside it.

The seven steps and what to say at each one

Comprehend (1-2 minutes). Ask one clarifying question that genuinely changes your answer. The word “genuinely” is doing real work: asking “who is the target user?” when the question already says “for commuters” is theatrical, not helpful. A good clarifying question narrows scope, surfaces a business goal, or identifies a constraint. “Are we trying to grow this to new users or deepen retention for existing ones?” is worth asking. “Is this greenfield or an improvement of what exists?” changes your whole approach.

Identify the customer (3-4 minutes). Segment the user base, pick one cohort, and say why. The failure mode is a demographic label with no behavior attached. “Adults 25-35 who are busy” is unfalsifiable. A strong cohort is defined by context and friction: “frequent podcast listeners who use Spotify as their primary app but also listen to music, and feel the jarring transition when they finish an episode.” That is specific enough to test.

Two-sided markets and vague prompts require an extra step. If the prompt gives you a platform (“design something for Airbnb”), you need to state which side you are designing for and why, then make clear you are aware the other side exists and may be affected.

Report customer needs (4-5 minutes). Name the underlying job, not the feature want. “Users want better recommendations” is a want. “Users need continuity across contexts, which shows up as frustration every time a natural transition point forces them to navigate instead of just continuing” is a job. Slow down here more than anywhere else. This step is where the answer is actually scored.

Cut via prioritization (2-3 minutes). Out loud and with a rationale. Use a three-axis scaffold: frequency of the pain, acuteness (how much it costs the user), alignment with the business goal you named in Comprehend. Say which need scores highest and why. “I’m prioritizing the episode-completion dead-end because it happens at the highest-frequency moment for this cohort, and every dead-end is a moment where they might open a competing app. That directly threatens the retention goal we set at the top.”

List solutions (2-3 minutes). Two or three meaningfully different options, not eight incremental variations. Lin originally suggested 10+ ideas; in practice, interviewers at senior levels want differentiation, not volume. A useful spectrum: one quick-win with narrow scope, one core bet that addresses the need directly, one longer-horizon idea worth naming even if you do not pick it. This shows range without padding.

Evaluate tradeoffs (1-2 minutes). In 2026, this step has changed. Spend minimal time on technical feasibility (nearly anything is buildable) and most of it on two questions: Is this a problem people or companies will pay to have solved at scale (viable)? Does this solution fit where users already work without asking them to form a new habit (lovable)? Those are the hard questions. If you spend three minutes on engineering complexity and thirty seconds on retention curve and willingness to pay, you are answering for 2018.

Summarize (2 minutes). One recommendation, one success metric specific enough to distinguish “it worked” from “people tried it once.” Name what you are trading away. Connect the recommendation back to the business goal you established in Comprehend.

Strong vs. weak: the same question, two candidates

Question: “How would you improve Google Maps for small-business owners?”

strong

"Before I dive in: are we trying to bring more small businesses onto Maps, or help ones already listed get more value from it? [Interviewer: existing businesses.] Got it. I'll focus on owner-operated local businesses, not chains with dedicated marketing teams. These are owners who listed their business, maybe added hours and a photo, and then forgot Maps exists as a tool. The underlying need isn't better analytics; it's confidence that the listing is actually working for them: they get no feedback loop today. Of the friction points I see, I'll prioritize the absence of a signal that tells an owner 'someone found you and came in because of Maps.' That pain is frequent, it maps to real revenue anxiety, and solving it is in Google's interest because owners who see ROI renew Google Ads. I'd build a lightweight attribution prompt: after a phone call or direction request through Maps, the customer gets a one-tap receipt and the owner gets an aggregate 'estimated visits from Maps this week.' This isn't a data dashboard; it's a confidence signal. I'm not recommending a full analytics suite because owners won't log in to use it. The success metric: 30-day active rate among claimed-listing owners, with a holdout. Secondary: Google Ads conversion among owners who see the attribution signal vs. those who don't."

weak

"So for C, I'm going to Comprehend the situation. Google Maps is a navigation and discovery app. For I, I'll Identify the customer. I'll say small business owners, like restaurants, salons, and retailers. For R, their needs are to get more customers. For C, I'll Cut. I'll focus on the biggest pain, which is visibility. For L, I'll List solutions: better SEO tools, review management, a business dashboard, a photo improvement tool, and maybe a way to add promotions. For E, the tradeoff is development complexity. I'd recommend the business dashboard because it helps the most owners."

The weak answer recites the acronym out loud (the single most reliable tell), treats user identification as obvious, conflates a feature want (“more customers”) with a specific need, generates five solutions without meaningful differentiation, evaluates tradeoffs purely on engineering complexity, and closes with no testable metric. That answer clears a 2015 bar. It fails a 2026 bar at any company actively building AI products.

Time budget across a 20-minute question

Most candidates distribute time evenly. That is a mistake.

Comprehend: 1-2 minutes. One question, confirm scope, move on.
Identify + Report + Cut: 10-12 minutes. This is where the answer lives.
List + Evaluate: 3-4 minutes. Feasibility is not a differentiator; move briskly.
Summarize: 2 minutes. One recommendation, one metric, what you are trading away.

Spending four minutes on the List step does not add signal. Spending four minutes on the Report step very often does.

What changes for AI product questions

AI product questions (“design an AI writing assistant for nurses”) break CIRCLES in one specific place: the Evaluate step’s traditional center of gravity (can we build it? how hard is the ML?) is gone. The question is never “can we build a summarization feature?” anymore. The questions are: Will nurses use this, or does it add a task to an already overloaded workflow? Does the output need to be editable, or is read-only enough? What happens when the model is wrong and a patient is affected?

For AI products, fold those three into your Evaluate step explicitly. Probabilistic outputs, cognitive offloading (the tool should reduce decisions, not add them), and error consequences belong in your tradeoff analysis alongside viable and lovable. Interviewers at Anthropic, OpenAI, and Cursor in 2026 are specifically testing whether candidates understand that the hard part of AI product design is not building the feature but understanding the failure modes.

Use it, do not recite it

Interviewers in 2026 flag AI-generated answers because they hit every CIRCLES step in order with no hesitation, no uncertainty, and no live thinking. A candidate who shows genuine thinking, handles a pushback without restating their original answer, and compresses steps when the question calls for it reads as a practitioner. One who announces “Now I’ll move to the L step” reads as someone who just read a blog post.

If an interviewer interrupts and says “let’s skip to solutions,” go there without anxiety. If they push back on your user selection, engage: “That’s a fair point, let me think about whether first-time vs. habitual users are the higher-value cohort here” is better than pivoting to the next bullet. CIRCLES is a mental checklist, not a presentation script.

The 2026 reframe

The original framework was designed when “can we build it?” was a genuine gating question. In 2026, feasibility is the floor, not the ceiling. This collapses the Evaluate step as traditionally taught. The evaluative weight has moved to viable (is this a problem people and companies will pay to solve, and is the market large enough to sustain the product?) and lovable (does the solution fit where users already work, does it anticipate needs without being obtrusive, and does it create genuine pull rather than obligation?).

Strong candidates compress List and Evaluate into a tight recommendation, spend more time on Comprehend (genuinely understanding what success looks like for the business) and Report/Cut (naming a specific user pain that is both frequent and costly enough to monetize), and treat feasibility as a brief checkbox. A candidate who spends the bulk of Evaluate on engineering risk and thirty seconds on retention and willingness to pay is signaling that their mental model is pre-2024.