Stop picking just one pain point. Start peeling back the layers of what makes products actually viable.

Picture this: You're in a product management interview, and you've just outlined six compelling pain points that your target users face. The interviewer leans back, impressed by your thorough analysis, then asks the killer question: "So which one are you going to focus on?"

Most candidates reach for the conventional wisdom: pick one pain point, build an MVP around it, ship fast, iterate. It's clean. It's focused. It's also often wrong.

The Minimum Product Trap

Here's the dirty secret about focusing on a single pain point: you don't get a Minimum Viable Product (MVP)—you get what I call a Minimum Product (MP). And minimum products don't survive in the real world.

Take the recent mock interview I conducted with a candidate designing a product for Google's design suite. He identified six legitimate pain points:

• Alignment on initial designs

• Rapid prototyping without getting stuck in polish

• Collaboration around design iterations

• Presentation of work to stakeholders

• Conversion from design to code

• Design quality assurance

Traditional interview wisdom would have him pick one—maybe collaboration—and build everything around that. But users don't live in single-pain-point bubbles. A design tool without presentation capabilities isn't viable. A collaboration platform that can't handle basic creation is dead on arrival.

Enter the Product Onion

The breakthrough came when the candidate introduced what he called "the onion approach." Instead of picking one pain point, he identified the "center of the onion"—a core canvas where users could create, collaborate, and present their designs. Each pain point became a layer that could be addressed at a basic level initially, then enhanced over time.

This wasn't feature creep. This was strategic layering.

The canvas became the hero feature—the thing that differentiated the product and solved the most critical user need. But it was surrounded by essential layers: lightweight collaboration (borrowed from existing Google tools), basic presentation modes (leveraging Google Slides infrastructure), and simple sharing capabilities.

The Antes Strategy: Borrowing from Poker

There's another metaphor that works beautifully here, borrowed from poker. Before you can play any hand, everyone at the table must put in an "ante"—a small bet that gets you into the game.

In product development, especially in hardware, antes are the non-negotiable features that make your product viable. Building a phone? You need a screen, power button, memory, and processing capability. These aren't optional—they're the price of admission to being called a phone.

Software products have antes too. Launching a productivity tool in Google Workspace without collaboration features? That's not an MVP, that's a non-starter. Building a design tool without basic presentation capabilities? You're not even in the game.

The key insight: antes don't have to be revolutionary. They just have to be sufficient. You can borrow, buy, or stitch together existing solutions for your antes, then pour your innovation budget into your hero feature.

The Strategic Art of Feature Layering

The magic happens when you think strategically about which pain points become your hero feature versus your antes. In the Google design tool example:

Hero Feature: The canvas creation experience—something truly differentiated that no competitor offered in the same way.

Antes:

• Collaboration (borrowed from Google Chat/Meet infrastructure)

• Presentation (quick export to Google Slides)

• Sharing (leveraging existing Google Drive permissions)

This approach solved multiple pain points without diluting focus. The team could ship something genuinely useful while maintaining a clear value proposition centered on the canvas experience.

Why This Matters Beyond Interviews

This isn't just interview theater. I use this framework constantly in real product management:

When stakeholders push for feature requests, I map them against our product's onion layers. Is this request enhancing our hero feature—the thing that truly differentiates us? Or is it adding a new ante that users now expect as table stakes? This clarity helps me prioritize ruthlessly and communicate trade-offs in language everyone understands.

The framework also transforms roadmap planning. Instead of a flat list of features, I organize initiatives by onion layers. Core improvements get premium development resources, while ante enhancements can often be solved through integrations, partnerships, or lightweight implementations. Teams stay focused on what matters most while ensuring we don't ship a minimum product.

The Implementation Reality

Here's what this looks like in practice:

• Month 1-3: Build the hero feature (canvas) with basic antes

• Month 4-6: Enhance the most critical antes based on user feedback

• Month 7+: Add new onion layers as the product matures

You're not building everything at once. You're building strategically, ensuring viability from day one while maintaining focus on what truly differentiates your product.

Beyond the Single Solution

The next time you're analyzing user pain points—whether in an interview or planning your actual product—resist the urge to pick just one. Instead, ask:

• What's my hero feature that truly differentiates this product?

• What are the antes—the basic capabilities users expect from any solution in this space?

• How can I address multiple layers of the onion without losing focus?

• What can I borrow, buy, or stitch together versus build from scratch?

The best products aren't solutions to single problems. They're thoughtfully layered responses to the complex, interconnected challenges that users actually face.

Your MVP should be viable, not minimal. And viable means having enough layers to survive in the real world—even if some of those layers start thin and grow over time.

The onion approach doesn't just make for better interview answers. It makes for better products. And in a world of failed minimum products, that might be the differentiation you need.