The CIRCLES Method
A seven-step structure for any “design a product” or “how would you improve X?” question — so you reason in the open instead of jumping to a feature.
▸ Try the interactive toolThe framework
The CIRCLES Method, created by Lewis C. Lin, is a seven-step framework for answering open-ended product design questions: “design a product for X,” “improve product Y,” or “how would you solve Z?” Each letter is a step you work through in order.
It began as a PM interview tool — a way to answer “how would you improve a maps app?” without rambling — but it's equally a working method for structuring any product brainstorm. Its value is that it forces you to comprehend the situation and the user before proposing a single solution, which is the exact discipline that separates a considered answer from a reflexive one.
Comprehend the situation · Identify the customer · Report customer needs · Cut through prioritisation · List solutions · Evaluate trade-offs · Summarise the recommendation
Try it yourself
What it prevents
Open-ended product questions punish two instincts: answering before you understand, and listing features before you've prioritised. CIRCLES blocks both.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Solving before understanding | You propose a feature in the first ten seconds and spend the rest defending a guess. | Comprehend and Identify come first — you can't solve until you've framed the situation and named the user. |
| Designing for everyone | Without a chosen customer, every idea seems valid and none is grounded. | Identify forces one specific segment, so needs and solutions have a target. |
| Feature soup | A long unranked list of ideas with no rationale. | Cut and Evaluate force prioritisation and explicit trade-offs. |
| No clear recommendation | The answer trails off without a decision. | Summarise demands one recommendation you'd actually stand behind. |
Step by step
Comprehend the situation
Restate the context, constraints, and goal in your own words. Clarify the question before answering it — what's the product, who's asking, what's the goal, what's fixed?
Identify the customer
Name one specific user segment to design for. Not “everyone” — a segment with a distinct situation and need.
Report customer needs
List what that customer is actually trying to accomplish — ideally as jobs or needs, not features. This is where JTBD plugs in.
Cut through prioritisation
You can't serve every need. Pick the one or two that matter most for this customer and this goal, and say why.
List solutions
Now — and only now — brainstorm solutions for the prioritised need. Several options, not one, so you have something to compare.
Evaluate trade-offs
Weigh the options against criteria that matter (impact, effort, strategic fit). Make the trade-offs explicit rather than picking a favourite silently.
Summarise the recommendation
State your recommendation in one or two sentences, with the reason. A clear decision, not a shrug.
A short illustration
A candidate asked to “improve a ride-share app” started listing features — better maps, loyalty points, in-app chat. The interviewer's notes read “unfocused.”
A second candidate ran CIRCLES: comprehended (the goal is rider retention), identified (occasional riders who churn after a bad first trip), reported their needs (predictability and trust), cut to the top need (reduce first-trip anxiety), listed three solutions, evaluated them, and recommended one — a driver-arrival confidence feature — with a reason.
The structured answer
The deliverable is a one-page response that walks visibly through all seven steps — so a reader can trace your reasoning from situation to recommendation.
| Step | What the reader sees | What it proves |
|---|---|---|
| Comprehend | A crisp restatement of the situation and goal | You understood the question before answering |
| Identify | One named customer segment | You designed for someone specific |
| Report | That segment's real needs / jobs | You grounded it in needs, not features |
| Cut | The one or two prioritised needs | You can choose under constraint |
| List | Several solution options | You explored, didn't fixate |
| Evaluate | Explicit trade-offs across options | You reasoned, didn't guess |
| Summarise | One clear recommendation | You can commit to a decision |
Why it matters
The structure is the answer. Interviewers and stakeholders aren't grading your idea — they're grading whether you can reason from situation to recommendation without skipping the user.
In real work, CIRCLES is a fast way to structure a brainstorm or a one-pager so it doesn't collapse into a feature list. The first four steps — comprehend, identify, report, cut — are where the quality lives; the last three just make your reasoning legible.
Common mistakes
The most common failure. Solutions proposed before the customer and need are framed are guesses. Force yourself through C–I–R–C first.
“I'd design for everyone” is the same as designing for no one. Pick one segment, even arbitrarily, and commit.
With a single option there's nothing to evaluate. The Evaluate step needs at least two or three to be meaningful.
Trailing off with “so there are lots of options” wastes the whole structure. Summarise with one pick.
When not to use it
- You already deeply understand the problem and user. If the framing is settled, the early steps are ceremony — go straight to solutions and evaluation.
- It's a small, well-scoped decision. CIRCLES is for open-ended design questions, not “should this button say Save or Submit.”
- You're past ideation and into execution. Once a solution is chosen and validated, CIRCLES has done its job — switch to delivery tools.
Where this sits in the toolkit
The “Report customer needs” step is strongest when fed by real JTBD analysis rather than imagined needs.
The “Cut” and “Evaluate” steps are informal prioritisation; RICE and ICE make them rigorous when stakes are high.
“Comprehend” and “Report needs” naturally produce a problem statement — the falsifiable sentence Tool 09 formalises.
CIRCLES is the default scaffold for product-design interview questions — worth practising until the seven steps are automatic.
Run CIRCLES on a product you use
Pick a product you use daily and answer “how would you improve it?” — but force yourself through all seven steps out loud, in order, without naming a single solution until step five.
Notice how different your step-five solutions are once you've actually chosen a customer and a need in steps two through four.
The ideas you'd have blurted in the first ten seconds are almost never the ones you recommend after running the structure. That gap is the method working.
New tools and AI deep-dives, occasionally.
No spam. Unsubscribe anytime.