CIRCLES Method

Seven steps, and a product design question runs about 35 minutes. Most candidates spend twelve of those minutes on step one and never reach step six.

That is the whole problem with the CIRCLES method. The structure is sound. The time allocation is what fails, and the two steps that decide the grade are the two that get cut when the clock runs out.

What is the CIRCLES method?

CIRCLES is a seven-step answer structure for product design questions, published by Lewis C. Lin in Decode and Conquer in 2013. The acronym spells the order you work in:

1. Comprehend the situation. Ask the clarifying questions that fix the scope.
2. Identify the customer. Name two or three distinct segments.
3. Report the customer's needs. State what each segment is trying to get done.
4. Cut through prioritization. Pick one segment and one need, and say why.
5. List solutions. Three ideas, briefly, at different levels of ambition.
6. Evaluate trade-offs. Compare them on something other than your own preference.
7. Summarize your recommendation. Thirty seconds, out loud, with the metric.

It was written for the question shape that still dominates PM loops at Google, Meta, Amazon and most companies that copied their interview design: "design a product for X," "how would you improve Y." The structure exists because unstructured answers wander, and a wandering answer reads as unstructured thinking even when the ideas are good.

How much time should each step get?

Here is the budget that keeps an answer inside 35 minutes. It is the single most useful thing to memorise about CIRCLES, because the acronym gives you an order and says nothing about weight.

Notice that the first three steps take ten minutes together and the last three take eighteen. Candidates reverse that ratio almost every time, because the early steps feel safe. Asking clarifying questions cannot be wrong. Proposing a solution can.

A worked CIRCLES answer: redesign the boarding pass

Before the walkthrough, one thing nobody tells candidates: in a product design question the numbers are yours to invent. No interviewer expects you to know how many domestic flights the United States runs. What they are grading is whether the number you invented in minute four is still the number you are using in minute twenty-eight.

Comprehend

"I'll assume we mean the mobile boarding pass inside an airline's own app, for domestic US flights, and that the goal is the passenger's experience rather than gate-agent throughput. Is that the right scope?" Four sentences. Scope fixed.

Identify and report needs

• The weekly business flier. Needs the pass in one tap at the gate, offline, with no hunting.
• The family of four. Needs four passes in one place, in boarding order, without switching screens while holding a toddler.
• The once-a-year flier. Needs to know they are at the right gate at the right time and that nothing is wrong.

Cut through prioritization

Pick the family. Now put a number on it, out loud, and label it as your own estimate: "Say the airline carries 90 million domestic passengers a year. Say a fifth of those travel in groups of three or more. That is 18 million passengers in group trips, roughly 4.5 million groups." Those figures are made up. You said so. What matters is that when you get to Evaluate you size the solution against 4.5 million groups and do not quietly switch back to 90 million passengers to make your idea look bigger.

List solutions

1. The obvious one: a single stacked card holding all four passes, swipeable, sorted by boarding group.
2. The structural one: one group QR code that the scanner reads once for the whole party, which means the airline has to change the scanner software and not only the app.
3. The bet: the pass becomes a live timeline that tells the family what to do next, gate change included, so the pass is the thing you check instead of the departures board.

Evaluate trade-offs

The stacked card is two sprints of client work and touches nothing else. The group QR code needs the airport hardware vendor and will not ship this year, which makes it the right roadmap item and the wrong answer to "what would you build first." The live timeline is the largest bet and it fails badly if gate data is late, because a passenger who trusts a wrong gate misses a flight. That last sentence is the one that earns points. It is a cost, stated without being asked.

Summarize

"Build the stacked group card first, for the 4.5 million group trips a year. Measure it on the share of group passengers who scan without reopening the app, and watch gate-agent scan time as a guardrail so a nicer app does not slow boarding. The group QR code goes on the roadmap behind a hardware conversation."

Where does the CIRCLES method break down?

Five failure modes, in the order they cost candidates offers.

1. It has no step for success metrics. The structure ends at Summarize. Many loops grade "how would you measure this" as a separate dimension, and a few ask it as the follow-up that decides a borderline score. Bolt a metric onto the end of Evaluate every time, the way the worked answer above does.
2. Saying the acronym out loud. "Now I'll comprehend the situation" is the clearest signal in the interview that a candidate is running a script. The structure should be invisible. An interviewer who cannot name your framework but can follow your logic is the outcome you want.
3. Step four gets skipped. Cut through prioritization is the shortest step and the one that carries the most weight, because it is the only place in the answer where you decide something under ambiguity. Candidates who list three segments and then design for all three have answered a different, easier question.
4. It was written for consumer products. On a platform, API or internal-tooling question, "identify the customer" needs two passes. There is the developer who integrates your thing and the end user who never sees it, and their needs conflict. Run Identify twice and say that you are doing it.
5. Seven steps invite even pacing. They are not evenly weighted, and an answer that gives each step five minutes will be shallow in exactly the two places the interviewer cares about. The table above exists for this reason.

How will an interviewer actually ask about CIRCLES?

They will not name it. The acronym almost never appears in the question itself. What appears is one of these four shapes:

• "Design a [product] for [segment]." The standard opener. CIRCLES fits as written.
• "How would you improve [our product]?" Comprehend becomes harder, because the scope is enormous. Cut early and say what you are ignoring.
• "Our CEO wants to enter [market]. What do you build?" This one hides a strategy question inside a design question. Do Identify and Report before touching solutions or you will design for a market you have not described.
• "You have one engineer for six weeks. What ships?" Evaluate moves to the front. The constraint is the question.

And if an interviewer does ask which framework you use, answer with behaviour rather than the acronym: "I scope it, pick a user, pick a need, put three options on the table and choose one with the cost named." That is CIRCLES, described by someone who has used it rather than memorised it.