Avoid PM Frameworks Trap and Learn How to Answer Product Design Questions
Evaluated 4+ Product Design Frameworks which says same thing but packed differently.
You probably spent collecting product frameworks like cricket cards, to clear Product Management Interviews.
CIRCLES Method. CUPS-PDM. The 7-Step Framework. Exponent’s Basic Product Design Framework. Every book, every blog post, every senior PM had their own “proven” way to approach product design questions or how to answer product design questions.
The result? Complete analysis paralysis when You actually had to design something.
Sound familiar?
The Framework Confusion Is Real
Here’s the thing—if you’ve ever looked at multiple product design frameworks side-by-side, you know exactly what I’m talking about.
All these frameworks are trying to solve the same problem—how to systematically approach product design. But they all say it differently:
CIRCLES Method™: Comprehend, Identify, Report, Cut, List, Evaluate, Summarize
CUPS-PDM Framework: Clarify, Define users, Problem, Solutions, Prioritize, Measure
The 7-Step Framework: Clarify, Define context, Identify pain points, Brainstorm solutions, Prioritize, Define product vision, Summarize
Exponent’s Framework: Ask questions, Provide structure, Identify users/customers, Map problems, Propose solutions, Wrap up
Look at that list. They all start differently. They all have different numbers of steps. Some want you to “comprehend” first, others say “clarify,” one says “ask questions.”
No wonder aspiring PMs feel lost.
It’s like being taught to cook biryani by four different aunties—everyone swears their method is the only correct one, but somehow they all make great biryani.
Why This Confusion Exists
Here’s what I learned after shipping 15+ features at Amazon: These frameworks aren’t actually different.
They’re just different ways of packaging the same underlying thinking process. It’s like having multiple navigation apps—Google Maps, Apple Maps, Map My India Maps—they all get you to the same destination, just with slightly different routes and interfaces.
The problem isn’t the frameworks themselves.
The problem is that we’re taught to memorize steps instead of understanding the why behind product thinking.
And here’s the uncomfortable truth: In every single interview I took, candidates bombed, they were mechanically following a framework.
You can only ace the Product Design Interview, if you are... thinking naturally about the problem.
What I Discovered: Product Thinking Is a Natural Process, Not a Framework
Remember: The best PMs don’t think in frameworks. They think in a natural flow that mirrors how we solve problems in real life.
When you’re helping a friend figure out what phone to buy, you don’t think
“Step 1: Comprehend the situation.” You naturally:
Understand what they need (budget, usage, preferences)
Map out their options (iPhone vs Android, flagship vs mid-range)
Prioritize what matters most (camera? battery? gaming?)
Make a recommendation
Explain the trade-offs
That’s it. That’s product thinking.
Over time, I developed my own thought process that I call COMPASS—not because it’s another framework to memorize, but because it’s a natural way of navigating product problems. Like an actual compass, it just points you in the right direction without telling you the exact steps to take.
COMPASS stands for:
Context - Understand the landscape
Objectives - Know what success looks like
Map Problems - Identify real pain points
Prioritize - Focus on what matters most
Articulate Vision - Define the solution clearly
Summarize & Scale - Wrap up with impact and next steps
But here’s the thing: I don’t use this as a rigid checklist. It’s more like... a mental model. A way of thinking that becomes natural after you internalize it.
And honestly? It’s basically the same as CIRCLES or CUPS-PDM or any other framework. Just organized in a way that made sense to my brain.
The Real Product Design Process (That Actually Works)
Whether you use CIRCLES, CUPS-PDM, the 7-Step Framework, or COMPASS, they all boil down to the same 3 fundamental phases:
Phase 1: Understand the Problem Space (Context → Map)
What you’re actually doing: Getting crystal clear on who you’re solving for and what pain you’re addressing.
This is what all those “Comprehend,” “Clarify,” and “Ask questions” steps are about.
In COMPASS, this is the Context and Map Problems part—but it’s not about following steps, it’s about genuinely understanding:
Who is the customer? (Be specific—not just “users”)
What job are they trying to do?
What’s painful about how they do it today?
Why does this matter to the business right now?
Example: When we were building a seller dashboard feature at Amazon, we didn’t jump to “sellers need analytics.” We spent time understanding that small sellers in Tier 2 cities specifically struggled to identify their top-performing products during Diwali and festive season prep because they managed inventory across multiple platforms—Amazon, Flipkart, Meesho, and their own WhatsApp business.
These sellers weren’t tech-savvy. They were juggling Excel sheets, WhatsApp messages from customers, and three different seller dashboards. The pain wasn’t lack of data—it was data overload without insights.
Another example: Think about Zepto or Blinkit’s 10-minute delivery promise. The problem wasn’t “people want groceries.” It was “urban millennials in metros don’t have time for weekly grocery shopping, hate stepping out in traffic, and are willing to pay a premium for convenience.” That specificity shapes everything—the product, the dark stores, the inventory selection.
This is where most frameworks say the same thing with different words:
CIRCLES: “Comprehend the situation” + “Identify the customer” + “Report customer needs”
CUPS-PDM: “Clarify” + “Define users” + “Problem”
7-Step: “Clarify” + “Define context” + “Identify pain points”
COMPASS: “Context” + “Map Problems”
See? Same destination, different route names.
Phase 2: Explore the Solution Space (Objectives → Prioritize → Articulate)
What you’re actually doing: Generating options and choosing the right approach.
This covers all those “List solutions,” “Brainstorm,” and “Prioritize” steps across different frameworks.
In COMPASS thinking, this is where Objectives (knowing what success looks like), Prioritize (focusing on what matters), and Articulate Vision (defining the solution) come together naturally.
You’re figuring out:
What are multiple ways to solve this problem?
What criteria matter most? (technical feasibility, impact, time to market)
Which solution aligns with our product strategy and business goals?
What’s the MVP vs. future vision?
The trap: Most PMs jump here too fast. They skip Phase 1 and start solution-ing immediately. This is why products fail.
Example: Let’s say you’re asked “How would you improve PhonePe?”
Bad approach: “Add crypto trading, add stock investing, add insurance!”
Better approach: First identify the user segment and objectives. Are we talking about:
Tier 1 users who already use PhonePe for everything?
Tier 2/3 users who only use it for UPI payments?
Small shopkeepers who receive payments?
Students who split bills?
Each segment has different pain points and different measures of success.
A shopkeeper in Varanasi doesn’t care about crypto—they want easy settlement tracking and simple accounting for GST.
A Bangalore techie might want investment options.
Solution exploration for the shopkeeper segment might look like:
Option 1: Auto-categorize incoming payments by customer/product
Option 2: One-click GST report generation
Option 3: Integration with Tally/accounting software
Option 4: Predictive cash flow forecasting based on payment patterns
Now you prioritize based on:
Impact (What solves the biggest pain?)
Feasibility (What can we build in 2 months vs 6 months?)
Strategic fit (Does this move us toward becoming a business OS?)
Success metrics (What moves our north star metric?)
This is where frameworks get slightly different in their emphasis:
CIRCLES: “Cut through prioritization” + “List solutions” + “Evaluate trade-offs”
CUPS-PDM: “Solutions” + “Prioritize” + “Define product vision”
7-Step: “Brainstorm solutions” + “Prioritize” + “Define product vision”
COMPASS: “Objectives” + “Prioritize” + “Articulate Vision”
Again, same core thinking, different packaging.
Phase 3: Validate and Specify (Summarize & Scale)
What you’re actually doing: Detailing how you’ll build it and measure success.
All those “Summarize,” “Measure,” “Wrap up” steps fit here.
In COMPASS, this is Summarize & Scale—bringing it all together with clear next steps and impact thinking.
You’re defining:
What exactly are we building? (features, user flows)
How will we know it worked? (metrics, success criteria)
What are the risks and how do we mitigate them?
What’s the rollout plan?
Example: Let’s continue with the PhonePe shopkeeper feature.
What we’re building (MVP):
Auto-categorization of incoming payments with custom tags
Weekly settlement summary sent via WhatsApp
One-tap export to Excel for accountant sharing
Success metrics:
Primary: 30% of shopkeepers create at least one custom category within first week
Secondary: 20% increase in monthly active shopkeeper users
Engagement: 40% of users export data at least once per month
Business impact: 15% increase in merchant transaction volume
Risks and mitigation:
Risk: Low adoption because shopkeepers don’t understand the feature
Mitigation: WhatsApp video tutorial in Hindi, Bengali, Tamil (top 3 languages), launched with local kirana influencers
Risk: Category creation is too complex
Mitigation: AI suggests categories based on payment descriptions, one-tap to accept
Rollout plan:
Week 1-2: Beta with 500 shopkeepers in Mumbai, Surat (high merchant density)
Week 3-4: Expand to 5,000 across top 10 cities, gather feedback
Week 5-6: Full rollout with regional language support
See how specific this gets? That’s what separates good answers from great ones.
All frameworks end similarly:
CIRCLES: “Summarize your recommendation”
CUPS-PDM: “Measurement & Risks”
7-Step: “Summarize & Scale”
COMPASS: “Summarize & Scale”
How to Actually Tackle Product Design Questions (The Natural Way)
Here’s my framework-agnostic approach that works in interviews, stakeholder meetings, and real product work:
1. Resist the Urge to Jump to Solutions
When someone asks “How would you improve Swiggy?” your brain wants to immediately say “Add more restaurant filters!”
Stop. Take a breath.
Instead, build context first (the “C” in COMPASS):
“Are we focused on a specific user segment—students, working professionals, families?”
“What’s the business goal—increasing order frequency, average order value, or new user acquisition?”
“Are we looking at food delivery specifically, or also Instamart?”
“Any geographic focus—metros vs Tier 2 cities?”
“Any constrain or timeline to follow?”
This alone puts you ahead of 70% of PMs.
Why this matters in Indian context: India is not one market.
A solution for Mumbai won’t work in Mysore.
A feature for Gen Z won’t resonate with Gen X.
Always clarify the segment and understand the context.
2. Structure Your Thinking Out Loud (But Don’t Name the Framework)
Based on my experience of Interviewing and talking with Product leaders, I learned that interviewers don’t just want the answer—they want to see HOW you think.
Instead of saying: “I’ll use the CIRCLES method...”
Say things like:
“Let me start by understanding the context and who we’re building for.”
“Before jumping to solutions, I want to map out the real problems users face.”
“Let me think through what success looks like here—our objectives and metrics.”
This shows structured thinking without sounding robotic.
Notice how this follows COMPASS naturally:
Context first
Objectives and problems
Then solutions
But I’m not announcing “Step 1, Step 2, Step 3.” I’m just thinking naturally.
3. Make It Customer-Centric, Not Framework-Centric
The best PMs I worked with at Amazon never mentioned frameworks. They just naturally talked about customers.
Instead of: “Using the 7-Step Framework, let me clarify the situation...”
Try: “Let’s start with who’s struggling the most. I’m thinking about first-time app users in Tier 2 cities who might not be comfortable with English vs power users in metros who order daily...”
See the difference? One sounds like you’re regurgitating a framework. The other sounds like you actually care about solving problems.
Example: If asked about Cred, don’t say “the users are credit card holders.”
Say “Cred’s core users are upper-middle-class urban millennials, typically 25-40, earning 8+ LPA, who already have 2-3 credit cards and are financially savvy. They value rewards and gamification.”
That specificity shows you understand the market context deeply.
4. Use Data and Specifics
Vague answers kill credibility. Specific examples build it.
Bad: “We should improve the onboarding experience.”
Good: “Based on typical onboarding drop-off rates in Indian fintech apps, where 50-65% of users don’t complete KYC, I’d focus on reducing steps from 7 to 4, adding Aadhaar-based instant verification, and showing progress indicators in vernacular languages.”
More Example:
Instead of: “Add payment options”
Say: “Add UPI AutoPay for subscriptions since 67% of Indian digital payment users prefer UPI over cards, and AutoPay reduces monthly churn by 15-20%”
Instead of: “Improve delivery experience”
Say: “In Tier 2 cities, address discoverability is the #1 delivery issue. Adding landmark-based addressing and Google Plus Codes can reduce failed deliveries from 12% to under 5%”
This is where understanding your objectives and being able to articulate your vision with data makes all the difference.
5. Always Close with Impact (Scale Your Thinking)
Don’t just list features. Explain why they matter and how they scale.
“This solution would reduce time-to-first-value from 10 minutes to 2 minutes, which typically increases activation rates by 25-30% based on industry benchmarks I’ve seen in Indian SaaS products.”
Example:
“By adding vernacular voice search to our grocery app, we can tap into the 90% of Indian internet users who prefer regional languages. Based on Google’s research, this could increase our addressable market from 150M English-speaking users to 600M+ regional language users, with Tier 2/3 cities showing 3x higher engagement with voice features.”
See? You’re not just building a feature—you’re unlocking a market. This is the “Scale” in “Summarize & Scale.”
The Truth About Frameworks (Including COMPASS)
After all this, here’s my honest take: Pick any framework—or none at all.
Seriously. CIRCLES, CUPS-PDM, the 7-Step Framework, COMPASS—it doesn’t matter which one. What matters is:
Understanding over memorization: Know the why behind each step, not just the what
Flexibility over rigidity: Don’t be religious about it. Skip steps that don’t apply. Add steps when needed.
Natural flow over mechanical execution: Make it sound like thinking, not reciting
I developed COMPASS not as another framework to memorize, but as a natural thought process that works like an internal compass—it guides you without constraining you.
Think of it like learning to drive.
First, you consciously think about clutch, gear, accelerator.
After 6 months, you’re driving without thinking about the steps.
Product thinking is the same—frameworks are training wheels until it becomes natural.
The goal isn’t to perfectly execute COMPASS or CIRCLES. The goal is to internalize the thinking so deeply that you don’t need to reference any framework at all.
Common Mistakes to Avoid (Especially in Indian Interviews)
Mistake 1: Announcing which framework you’re using
“I’m going to use the CIRCLES method here...”
Nobody cares. Just think clearly. Structure your answer naturally without mentioning the framework name.
I’ve seen candidates lose offers because they mechanically went through CIRCLES even when the interviewer wanted to go deep on one aspect. Read the room.
Mistake 2: Forgetting the business context and objectives
Every product decision needs to tie back to business goals. “This improves user experience” isn’t enough.
In the Indian startup ecosystem especially, where funding has tightened and profitability matters, you can’t just say “this improves UX.”
You need to say “this improves UX AND reduces CAC by 20% because organic referrals increase.”
Know your objectives. Always.
Mistake 3: Not validating assumptions
The best answer to a product question often includes “Here’s what I’d need to validate first...” because it shows you know what you don’t know.
Example: “I’m assuming our target users have smartphones with 4G connectivity. In Tier 3 cities, if many users are still on 3G or have patchy connectivity, this solution won’t work—we’d need to design for offline-first.”
Mistake 4: Ignoring India-specific nuances and context
Don’t blindly copy Western product patterns. India is different:
Price sensitivity is real (that’s why Jio succeeded)
Data costs matter (that’s why YouTube Go existed)
Trust is earned slowly (that’s why COD still dominates)
Regional diversity is massive (that’s why vernacular matters)
Family decision-making is common (that’s why products like Khatabook work)
Always think: “Would this work in Indore? In Coimbatore? In Patna?” Not just in Bangalore and Gurgaon.
Understanding context deeply is critical in the Indian market.
Mistake 5: Over-engineering the answer
In a 30-minute interview, you don’t have time for a 45-minute answer. Be concise and go deep where it matters most.
Indian interviewers appreciate structured, crisp communication. Don’t ramble. Know when to prioritize and when to summarize.
Mistake 6: Treating frameworks like magic formulas
Frameworks don’t get you the job. Clear thinking does.
I’ve interviewed candidates who executed CIRCLES perfectly but still got rejected because they didn’t show genuine product sense. And I’ve seen candidates who never mentioned a framework but got offers because they asked insightful questions and showed they deeply understood customers.
The framework is a crutch. Product thinking is the skill.
Practice That Actually Works
Here’s what helped me improve:
1. Record yourself answering product design questions. Watch it back. You’ll cringe, but you’ll learn.
Use questions like:
“Design a product for Indian farmers”
“How would you improve Mumbai’s local train experience?”
“Build a SaaS product for small restaurants in India”
Watch for:
Are you jumping to solutions too fast? (skipping context and problem mapping)
Are you being specific about users? (or just saying “users”)
Are you tying back to business objectives? (or just listing features)
2. Do mock interviews with other PMs. Join communities like:
Product Folks India
PM Circle India
APM groups on LinkedIn
Ready to master PM interviews and land genuine product roles?
Participate in the Extended version of Beta Users?
Early access to Public Launch with PRO benefits.
A Slack community to voice out the bugs and get help on learning Product Interviews.
Test the platform and see how it get developed.
If yes then submit your form
3. Analyze real products you use daily.
Pick apps like Swiggy, CRED, Zepto, PhonePe and mentally work through COMPASS:
Context: Who is this feature for? What’s the market situation?
Objectives: What success metrics are they optimizing for?
Map Problems: What specific user pain does this solve?
Prioritize: Why this feature now? What did they say no to?
Articulate Vision: What’s the MVP vs future vision?
Summarize & Scale: What’s the impact? How does this scale?
Example exercise: CRED’s cashback store
Context: Credit card users with accumulated CRED coins, gamification-focused platform
Objectives: Increase engagement, reduce coin liability, create upsell opportunities
Map Problems: Users don’t know what to do with coins, need redemption options beyond bill payments
Prioritize: Start with popular brands, easy integration (vs building everything)
Articulate Vision: MVP = Brand vouchers; Future = Full marketplace
Summarize & Scale: Drives daily app opens, reduces accumulated coin balance, creates new revenue stream through brand partnerships
4. Read product teardowns from:
Ken’s Newsletter (Indian PM perspective)
Product Disrupted (Aakash Gupta)
Lenny’s Newsletter (global, but insightful)
Reforge case studies
Look for how they think, not what framework they use.
5. Study Indian product successes and failures
Don’t just learn from Silicon Valley. Study:
How Meesho built for Bharat (context = Tier 2/3, objectives = reseller growth)
How PhonePe won UPI (prioritized simplicity over features)
How Zepto made 10-min delivery work (articulated clear vision with dark stores)
How CRED gamified credit cards (mapped problem = credit cards boring, made them fun)
How Dunzo died (objectives misalignment = tried to do too much, didn’t prioritize)
Failures teach more than successes.
What’s your go-to approach for product design questions? Have you faced framework confusion? Drop a comment below—I read and respond to every one.
Want to get better at Product Management?
I share practical PM insights, interview strategies, and real examples from my time at Amazon in my weekly newsletter. No fluff, just actionable advice you can use in your PM interviews and day-to-day work.
I also share more about the COMPASS thinking process and how to develop natural product sense (not just framework memorization).
Join 10,000+ aspiring and current PMs who are leveling up every week. 👇
If you found this helpful, hit the ❤️ button and share it with someone preparing for PM interviews. It helps more people discover this content.