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 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
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. |
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?
Name one specific user segment to design for. Not “everyone” — a segment with a distinct situation and need.
List what that customer is actually trying to accomplish — ideally as jobs or needs, not features. This is where JTBD plugs in.
You can't serve every need. Pick the one or two that matter most for this customer and this goal, and say why.
Now — and only now — brainstorm solutions for the prioritised need. Several options, not one, so you have something to compare.
Weigh the options against criteria that matter (impact, effort, strategic fit). Make the trade-offs explicit rather than picking a favourite silently.
State your recommendation in one or two sentences, with the reason. A clear decision, not a shrug.
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 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 |
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.
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.
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.
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.