CHUS method > CIRCLES method
Lewis Lin’s CIRCLES method is a popular framework for tackling the type of product design questions that commonly show up in product management interviews. I found the framework helpful as a starting point, but cumbersome in practice. As a result, I created a simplified reformulation that I find superior.
It’s called CHUS — an acronym for Context, Humans, Uses, Solutions.
Let’s first review what a product design question is, then look at the CIRCLES method and its shortcomings. Finally, I’ll show you the CHUS method.
Product design questions
Product design questions are meant to produce a signal on your ability to take a big ambiguous problem and turn it into a great product or feature.
Facebook calls these “product sense” questions. They’re looking to see structured thinking going from macro — can you identify and justify user segments, key paint points, and product goals — to micro — what solutions would you build to address those pain points?
Typical questions will look like this:
- Improve product X.
Eg: Dropbox recently asked, “How would you improve Slack?” - Design a new product that does X.
Eg, Facebook recently asked, “Design a product to help consumers find a doctor.” - Design a product for group X.
Eg, Google recently asked, “Design a refrigerator for the blind.”
I actually enjoy practicing these kinds of questions because this really is the kind of thinking that you have to do a lot of as a PM — taking some broad, poorly constrained provocation, making sense of it and figuring out what to do about it.
Now let’s look at Lin’s framework for tackling these kinds of questions.
CIRCLES Method
Lin’s CIRCLES method has seven steps — one for each letter of the word CIRCLES. They are:
- Comprehend the situation
- Identify the customer
- Report customer needs
- Cut, through prioritization
- List solutions
- Evaluate tradeoffs
- Summarize recommendation
What I like about the framework is that these are indeed seven good things to think about, in that order. It works well as a starting point.
There are a few things that I don’t like about it.
The first is that it has seven steps, which is quite a lot to hold in mind at once. It’s hard to quickly recall them all and outline a response in my head.
The second problem is that while the word “CIRCLES” is easy to remember, the letters of the acronym don’t point to words that are useful to remember. “I” stands for “Identify” — identify what? The customer? Pain points? Solutions? Risks? The issue is that Lin formed the acronym around the verbs, but the verbs are practically interchangeable, like the action words on a resume (“delivered”, “achieved”). I suspect that interchangeability is actually why he did it: he chose to prioritize a nice-sounding acronym over useful pointers.
The third problem is that the framework is ontologically inelegant. What’s going on as you work through a question is that again and again you’re going wide to explore a space of possibilities and then narrowing down to choose a specific possibility to explore. First you do this around customer segments, then around needs, then around solutions. In CIRCLES, sometimes those diverge/converge steps are called out explicitly, and sometimes not. The Customer has one step, Needs and Solutions each are given two. This inelegance makes the framework harder to adapt on the fly — kind of like the way a piece of procedurally-written software is harder to adapt and extend than a piece of object-oriented software.
I find it cumbersome to work with CIRCLES so I changed it up and simplified it. Now let’s look at the CHUS framework.
CHUS Method
Here we have four steps:
- Context
- Humans
- Uses
- Solutions
At each step, we’ll do some version of the classic design diamond: diverge by creating choices, then converge making choices.
As you work through the case, it’s critical that you manage complexity. You’ll only have time to explore a tiny piece of the problem. Repeating the diamond will allow you to show that you know how to structure a complete exploration, while maintaining tractable complexity.
Here’s what it looks like.
At the context step, diverge by asking questions. Where’s this coming from in the org? Who am I in the example? Who’s it for? Why is it needed? Then converge by synthesizing: “Okay, we’re a national garage door lift manufacturer who sees an opportunity to gain market share by getting into the smart home space.”
At the humans step, diverge by listing all the stakeholders you can think of. Customers, manufacturers, insurers, company employees and directors, law enforcement, etc. Within the customers group, list segments. Converge by prioritizing: in almost every case the primary stakeholder that you’ll focus on is the customer. Select a segment and offer rationale.
At the uses step, diverge by listing needs, wants, and pain points for the user. Explore the normal solutions and use cases. Converge by selecting a specific use case. As a ___, I want ___ so that ___.
At the solutions step, diverge by listing possible solutions that address the user’s goals and pain points. Converge by prioritizing solutions and identifying the best one.
The benefits of CHUS over CIRCLES are simplicity and elegance. Yes, you have to learn two frameworks: the CHUS sequence, and the diverge-converge method. But separating these objects out lets you see each one individually more clearly, and lets you modulate its use as appropriate to the question.
Additional benefit — the CHUS acronym, if pronounced as “choose”, points to something that you have to do a lot of in these kinds of questions: choose where you’re going to focus. You can’t cover the whole problem space in 20 minutes. You have to again and again choose which branch of the tree you’re going to explore.