If you've done any PM interview prep, you've encountered CIRCLES. It's the most widely cited product design framework in the PM world, referenced in prep books, courses, and guides everywhere. It's also the most commonly misused.

This guide covers what CIRCLES actually is, how to use it correctly, where it breaks down, and how it fits alongside the other frameworks in your toolkit. If you read Monday's complete product design interview guide already, this is the natural companion piece (same question type, different framework, with two full worked examples).

What CIRCLES Stands For

CIRCLES was popularized by Lewis Lin, a PM coach and author. It's a 7-step structure for approaching product design questions:

Letter	Step	What it means
C	Comprehend the situation	Clarify the goal, scope, and context
I	Identify the customer	Define who you're designing for
R	Report the customer's needs	Articulate their job to be done and pain points
C	Cut through prioritization	Choose which customer need to focus on
L	List solutions	Generate multiple solutions
E	Evaluate trade-offs	Assess pros, cons, and feasibility of each
S	Summarize your recommendation	Commit to a clear recommendation with metrics

When executed well, CIRCLES ensures you don't skip any step in the design process, especially the early steps (user definition and needs articulation) that most candidates rush through.

When CIRCLES Works

CIRCLES is particularly useful in a few situations:

If you're newer to structured product thinking. The seven steps give you a cognitive checklist. When you're under pressure and your mind goes blank, the acronym gives you something to fall back on rather than improvising.

If you tend to jump to solutions. If your natural instinct is to start proposing features within the first 30 seconds of a question, CIRCLES is a forcing function. It makes it structurally impossible to reach solutions before you've defined the user and their needs.

For highly ambiguous questions. "Design a product for X" with no additional context benefits from a deliberate step-by-step walkthrough. CIRCLES gives you a sequence to follow even when the problem space is completely open.

When CIRCLES Gets Candidates in Trouble

Used mechanically, CIRCLES produces answers that are structurally correct but feel hollow. Three things to watch for:

Announcing the framework out loud. "I'm going to use the CIRCLES framework. Step one: Comprehend the situation..." is the fastest way to signal that you're reciting a playbook rather than thinking. Interviewers can tell. The framework should shape your answer invisibly, not be your answer.

Shallow execution on steps 1–4. The most common failure mode: spending 20 seconds each on Comprehend, Identify, and Report, then spending four minutes on solutions. The depth you put into the early steps determines the quality of everything that follows. Step I ("the customer is... frequent travelers") and Step R ("they want... an easier booking experience") with no specifics aren't doing the work the framework promises. Slow down on those steps.

Treating Evaluate as a formality. "Pro: improves UX; con: takes engineering time" applied to every option is not evaluation; it's placeholder text. Real evaluation means naming specific risks, comparing options along consistent dimensions, and actually eliminating some. If you end Step E with all three options still on the table, you haven't evaluated.

CIRCLES vs. Goal → User → Solution

We cover the Goal → User → Solution framework in depth in PM Interview Frameworks: Which One Should You Use? and in the full product design guide. How do the two compare?

	Goal → User → Solution	CIRCLES
Steps	6	7
Prescriptiveness	More flexible	More prescriptive
Key difference	Combines user identification and needs articulation into one step	Separates "Identify customer" (I) and "Report their needs" (R) into distinct steps
Best for	Candidates who naturally think in user problems first	Candidates who benefit from a more explicit checklist
Main risk	Rushing through the user definition	Running steps mechanically without depth

The practical difference is that CIRCLES forces an extra separation between "who is the user?" and "what do they need?" which can be valuable if you tend to define users too quickly. Goal → User → Solution gives you more flexibility in how you structure the middle of your answer.

Both frameworks arrive at the same place. The choice is mostly about which sequence your brain executes most reliably when someone is watching.

A Full CIRCLES Walkthrough: Improving Airbnb for First-Time Hosts

Let's run all seven steps explicitly. This is what good CIRCLES execution looks like in practice.

C: Comprehend the Situation

Before I start, I want to make sure I understand the goal. I'll assume Airbnb wants to increase the number of active hosts, specifically by improving conversion from 'listing created' to 'first booking received,' since that's the activation problem for new hosts. Is that a reasonable framing?

The interviewer confirms. You've scoped the problem and shown that you start with goals, not assumptions.

I: Identify the Customer

I want to focus on a specific first-time host segment rather than all new hosts. I'll choose: the accidental landlord, someone with a property available (a spare room, a second home, or their own apartment while they're traveling) but no prior hospitality experience. They're motivated by income, curious about Airbnb, but anxious about what being a host actually involves.

One segment. Specific details. Clear motivation and anxiety.

R: Report the Customer's Needs

This host has three distinct needs: confidence that they won't get a bad guest, clarity on what's expected of them (response time, cleanliness standards, check-in logistics), and help setting a competitive price. The biggest emotional friction point is the gap before the first booking. They've created a listing, they're waiting, and they don't know if they're doing anything wrong or if they're just invisible in the marketplace.

Not "users want an easy experience." A specific, layered articulation of functional and emotional needs.

C: Cut Through Prioritization

I'm going to focus on the pre-first-booking anxiety, because that's where hosts drop off or abandon the platform entirely. Once someone successfully hosts their first guest and gets a positive review, retention is dramatically higher. The feature that gets them through that first experience is the highest-leverage thing Airbnb can build for this segment.

You've committed to a problem space. Everything downstream has a direction.

L: List Solutions

Three options to address pre-booking anxiety:

Host Readiness Score: A dashboard showing first-time hosts what they've completed and what's missing before their listing is competitive: photo quality rating, response time setup, description completeness, and pricing relative to neighborhood. Actionable and visible.
Guaranteed First Booking Program: Airbnb proactively matches new hosts with vetted guests for their first booking, with reduced friction and possibly a discount. New hosts get a "soft launch" experience with lower stakes.
Peer Mentor Matching: New hosts are matched with experienced hosts in their area who've opted in to answer questions. Community-based confidence building.

E: Evaluate Trade-Offs

Host Readiness Score: High feasibility; most of the inputs already exist in Airbnb's data. Directly addresses the "am I doing this right?" anxiety. Doesn't require new supply or coordination. Risk: if the score looks good but the listing still doesn't get bookings, it could increase frustration rather than reduce it.

Guaranteed First Booking: Directly eliminates the fear by removing uncertainty. High impact if it works. High cost; Airbnb is subsidizing this, and it doesn't scale indefinitely. Works better as a limited pilot than a permanent feature.

Peer Mentor Matching: Strong trust-building potential in principle. But it relies on experienced host participation that Airbnb can't guarantee. Scales poorly. Eliminated.

Between A and B: I'd eliminate B as the primary feature; it's operationally complex and not scalable. It could work as an experiment. Option A is my recommendation because it's sustainable, improves supply quality across the board (not just for new hosts), and addresses the specific anxiety around "am I competitive?" rather than just "am I safe?"

S: Summarize the Recommendation

I'd build the Host Readiness Score as the primary intervention. It surfaces immediately after listing creation, shows a clear score with specific gaps and actionable steps, and includes pricing recommendations relative to comparable listings in the neighborhood. The score should update in real time as the host makes improvements.

Success metrics: I'd measure conversion from listing created to first booking received, segmented by users who engaged with the score vs. those who didn't. Secondary: average score at time of first booking (a proxy for listing quality improvement), and NPS among first-time hosts post-first-booking.

A Second Example: CIRCLES in Natural Prose

The first example walked through each step explicitly. This one shows what a CIRCLES answer sounds like when the structure is invisible, which is the goal in an actual interview.

The question: "How would you design an AI feature for a B2B SaaS product that helps customer success managers reduce churn?"

A strong spoken answer:

Before I design anything, I want to anchor on what success actually looks like here. I'll assume the goal is to reduce churn in the 60 to 120 day window. That's typically where at-risk accounts become visible but before a cancellation decision has been made. Let me know if you'd like me to focus on a different stage.

For the user, I want to pick someone specific. I'd focus on a customer success manager at a mid-market SaaS company managing 40 to 60 accounts. That's too many to give each one deep attention, but too few to justify a fully automated approach. Their job is to be proactive, but in practice they spend most of their day reacting: responding to support tickets, fielding escalations, joining calls when things are already bad. They don't have a reliable signal for which accounts are heading toward churn before the customer says so.

The core pain is signal timing. By the time a CSM notices an account is at risk (usage dropping, fewer active users, NPS declining) there's often only weeks left to reverse it. The window where intervention is both possible and effective has already closed.

With that in mind, three directions. First, a churn risk score surfaced proactively in the CSM's daily view: a model combining product usage signals, support ticket sentiment, and engagement frequency, ranked by urgency with a recommended action for each. Second, an AI-generated account brief delivered before any customer call showing what's changed in the last 30 days, what's at risk, and what the customer said in their last three interactions. Third, automated draft outreach: the AI proposes a personalized check-in message for at-risk accounts based on what it knows about that customer's use case, which the CSM reviews and sends.

I'd prioritize the churn risk score with recommended actions. It changes the CSM's daily behavior without adding a new task to their workflow. The account brief is only useful when a call is already scheduled; it doesn't change proactivity. The draft outreach is the highest-leverage option long term, but requires the model to be accurate enough that CSMs trust it, which takes time. The score builds that trust incrementally.

For success metrics, I'd track two things: CSM engagement rate with flagged accounts within 48 hours of the alert surfacing, and 90-day churn rate for flagged accounts versus a control group. If the feature is working, that delta should be measurable within one quarter.

Why this answer works:

The opening doesn't propose a feature; it scopes the problem. Anchoring on "the 60 to 120 day window" does two things: it shows the interviewer you start with outcomes rather than solutions, and it creates a clear criterion for evaluating everything that follows. That's the Comprehend step, but it sounds like strategic thinking, not a checklist being run.

The user definition goes three levels deep: who they are (a CS manager at a mid-market company), what their job is (proactive account management), and where the real friction lives (reactive by default, no early signal). The Identify and Report separation forces this depth. Without it, every solution becomes "something for CSMs" rather than something that solves the timing problem specifically.

The pain point is named before any solution appears. "The core pain is signal timing" is a one-sentence bridge that tells the interviewer: everything I'm about to propose exists to solve this specific problem. Any solution that doesn't address signal timing doesn't belong in the answer. This is the Cut step made concrete without announcing it.

The three solutions are genuinely different in kind. A risk score changes the daily view. An account brief changes pre-call preparation. Draft outreach changes how signals become actions. That variety is what makes the evaluation meaningful: the trade-offs are real, not cosmetic.

The prioritization gives a reason, not a preference. "The account brief is only useful when a call is already scheduled" is a concrete objection. "The score builds trust incrementally" is a strategic argument for sequencing. The CSM doesn't need to change their behavior on day one to get value from the score; that's the point.

The metrics are outcome-based and testable within a quarter. Closing with a specific measurement window signals you think beyond the design decision to how you'd actually validate it.

How CIRCLES Connects to the Rest of Your Framework Toolkit

CIRCLES is one of four frameworks you'll use across different PM interview question types. The others (STAR for behavioral questions, Segment → Estimate → Sanity Check for estimation, and Goal → Landscape → Recommendation for strategy) are covered in the PM Interview Frameworks overview.

The analogy between CIRCLES and STAR is worth noting: both frameworks exist to stop you from answering the wrong thing. STAR stops you from giving vague, hypothetical behavioral answers by forcing you to ground everything in a specific past situation. CIRCLES stops you from proposing features without grounding them in a user problem.

If you haven't built your STAR story bank yet, the behavioral interview guide covers that in depth; it's the other framework you'll use just as often as CIRCLES.

The Practice Problem That Never Changes

You can read every frameworks guide ever written and still freeze when the question is in front of you. The knowledge isn't the constraint.

The constraint is that PM interviews test performance, not knowledge. And performance only improves through deliberate practice in conditions that resemble the real thing, which means speaking your answers out loud, timed, with someone evaluating you.

CIRCLES, like STAR, becomes automatic only after extensive spoken repetition. Reading this guide tells you what to do. Practicing dozens of times tells you whether you can actually do it under pressure.

Practice product design questions with Cala Voice →

How to Use the CIRCLES Method for Product Design Interviews