CIRCLES for AI Product Design (with an AI Overlay)

CIRCLES is the classic product design framework, and on its own it produces a perfectly competent, completely generic answer. The thing that turns a generic product answer into an AI PM answer is a four part overlay you bolt on at the solution step. Data, model, eval, guardrails. Learn CIRCLES, then learn to add the overlay, and you can tackle any design an AI product for X prompt without freezing.

So here's the plan. First I'll walk you through CIRCLES, all seven steps, quickly, because the letters are just a memory aid. Then I'll show you where the AI overlay slots in and why an AI feature lives or dies on those four things a normal feature never has to worry about. Then one full worked example so you can hear the whole thing spoken end to end.

CIRCLES is seven steps. The real value isn't the acronym, it is that it forces you to scope before you solve and to commit at the end. C is comprehend the situation. Ask clarifying questions. What is this product, who's it for, what's the constraint? Platform, scale, is this real time or batch, which parts are genuinely AI versus rules?

Spend real time here. Call it two minutes of a design answer, and don't rush it to look fast. I is identify the customer. Pick one user segment. Not everyone. A specific persona in a specific context. New graduates job hunting, not job seekers. R is report the customer's needs. State their top pains and jobs to be done as clear needs.

Something like, I need to know if my resume matches this job before I waste an application. The second C is cut through prioritisation. You can't solve every need, so pick the one or two that matter most, and say why. Frequency, pain, business value. This is where you actually show judgement, so don't skip past it. L is list solutions.

Now generate a few solution ideas for the prioritised need. Breadth here, but briefly. E is evaluate tradeoffs. Compare the solutions, pick one, and commit. Name what you're giving up by picking it. And S is summarise. Restate the user, the need, the solution you chose, and how you'd measure success. Land the plane. That's a solid product answer. But for an AI product, the list solutions and evaluate steps are where you add the overlay, because an AI feature has four concerns a generic feature doesn't.

Here are the four. You weave them into your solution rather than reciting them as a list. First, data. Where does the data come from to make this work? For any AI feature, ask, is there labelled data, or a signal I can log to create it? What's the cold start problem before I have any data? If you can't answer where the training or grounding data comes from, the feature isn't real yet.

This is the single question that separates PMs who've shipped ML from PMs who've only read about it. Second, model. What's the actual ML problem, named precisely? Is it classification, regression, ranking, generation, retrieval? Do you need a big frontier model, or will a small fine tuned one do the job cheaper? Naming the ML problem, like saying this is a ranking problem or this is retrieval plus generation, is a strong AI depth signal.

We'd use AI is not. This is a regression on delivery time is. Third, eval. How do you measure that the AI is good, before and after launch? Offline golden set, plus an online metric. If your feature generates text, what does good even mean, and how would you score it? An AI design answer with no eval plan has a hole in it, and a frontier lab interviewer will walk straight into it.

Fourth, guardrails. What happens when the model is wrong, or gets misused? What's the failure case, and how do you contain it? Confidence thresholds, a say I don't know path, a human handoff, citations, an undo. This is the safety judgement column from the scorecard lesson, and skipping it at a lab is a no hire. Now, the key move.

You don't tack these on as a separate checklist at the end. You weave them into the solution. Listen to the difference. I'd build X. The data comes from Y. It's a ranking problem, so I'd use Z. I'd measure it with this golden set offline and this metric online. And when it's unsure, it does this instead of guessing.

That single paragraph is the thing a generic PM can't produce and an AI PM can. Let me walk a full one. Prompt: design an AI feature for a language learning app. Comprehend first. I'd clarify: it's a mobile app, millions of learners, and the AI feature should help people actually get fluent, not just grind drills. I'll assume real time, and on device where possible for latency.

Identify. I'll pick the intermediate learner, the one who can read and write but freezes the moment they're in a live conversation. That's the painful, underserved segment. Report needs. They need low stakes speaking practice, honest feedback on pronunciation and grammar, and to not feel judged while they do it. Cut through. I'll prioritise conversational speaking practice over yet another grammar drill, because speaking is their real blocker, and no drill fixes it.

List solutions. A voice chat partner AI, a pronunciation scorer, a role play scenario generator. Evaluate and commit. I'll build the AI voice conversation partner, with role play scenarios layered in. Now the overlay, woven in. Data: transcribed learner speech with corrections is the signal. Cold start is solved two ways, scripted opening scenarios, and a pronunciation model trained on existing labelled speech.

Model: it's speech to text, then an LLM for the conversation, then a scoring model for pronunciation and grammar, so it's a pipeline, not one model. Eval: offline, a golden set of learner utterances with expert rated corrections, measuring whether the AI's feedback agrees with a human tutor, and online, lesson completion and conversation length. Guardrails: when the speech recogniser's confidence is low, say it's an accent it doesn't handle well, it must not confidently correct a learner who was actually right, so below a confidence threshold it asks them to repeat rather than marking them wrong.

A wrongful correction is the exact failure case that makes a learner quit the app. Summarise. For the intermediate learner who freezes in conversation, an AI voice partner with role play, grounded in real corrective data, measured against human tutor agreement, and careful not to punish accents it can't quite hear. That answer scores, because the overlay turned a nice idea into a system with data, a named ML problem, an eval, and a designed failure case.

Let me show the overlay works on a totally different prompt, so you trust it. Design an AI feature for an email client. Cut through: I'll prioritise triage, sorting the inbox by what actually needs a reply. Overlay in one breath: the data is the user's own reply history, who they respond to and how fast, which is a beautiful built in label.

It's a ranking problem, order threads by predicted need to reply. Offline eval is a golden set of past inboxes where I know what the user actually replied to, and online it's time to first reply. And the guardrail is that a false demote is worse than a false promote, because a buried urgent email is the failure that loses trust, so I tune the threshold to over surface rather than hide.

Same overlay, different product, and it still holds. Notice what the overlay quietly did in both examples. It forced a real data source instead of we'll gather data somehow. It forced a named ML problem instead of we'll use AI. It forced a way to measure good before you've shipped. And it forced you to say what happens when the model is wrong.

Those are the four holes a generic answer leaves open, and an interviewer probes every one of them, so it's far better to close them yourself, in your own words, than to have them pried open by a follow up question you didn't see coming. A few things that quietly sink this answer. The trap here is thinking CIRCLES alone is enough for an AI question.

It gives you structure, but the answer stays generic without the overlay. The overlay is the AI part. Second trap, listing every feature you can think of. No. The cut through step exists precisely so you pick one thing and go deep. Breadth with no pick reads as an inability to prioritise. Third, treating the overlay as a checklist you recite at the end.

A tacked on 'and we would have evals' is much weaker than saying 'here is the golden set and what it measures'. And the last one, skipping guardrails to save time. That guardrail is the highest signal thirty seconds of an AI design answer at a safety focused company. Never cut it. So the whole shape. CIRCLES to scope and commit, comprehend, identify, report needs, cut through, list, evaluate, summarise.

Then, at the solution step, the four part overlay, data, model, eval, guardrails, woven straight into what you'd build rather than listed afterward. Every product sense question in this course runs on this. Design an AI product for ride sharing, productise text to music, improve ChatGPT for enterprise. This is the walk. Memorise this. CIRCLES to scope and commit, then the overlay at the solution step, data, model, eval, guardrails.

That overlay is what makes it an AI PM answer instead of a generic one.