Most founders have a secret addiction: over-architecting solutions. You’ll find yourself building an elaborate system when a simple spreadsheet would do, or designing a complex feature before you've even validated the core need. Sam Parr admits he falls into this trap all the time. He calls it trying to find a way around the problem instead of going through it.

His former boss, EbT (from Twitch and YC), had a brutal, elegant way to cut through this tendency. When Parr or another founder would lay out their grand, convoluted plan, EbT would simply ask, “Have you tried solving the problem?” This isn't generic advice. This is a shock-value question designed to snap you back to reality when you’re convincing yourself that an elaborate workaround is the only solution.

The core insight? “The only way out is through.” You’re not special. Your problem probably doesn’t need a seven-layer dip of software and integrations if a direct, even manual, approach can prove the concept or fix the immediate pain point faster. For many YC startups, Parr says this is the most common advice he gives. They present a complex plan, and he brings them back to EbT’s simple truth.

Key Takeaways

  • Founders, including Sam Parr himself, often gravitate towards over-architecting solutions rather than addressing problems directly.
  • This tendency often manifests as searching for an elaborate "way around" a problem instead of going "through" it with direct action.
  • EbT's simple, blunt question, "Have you tried solving the problem?" serves as a specific mental circuit breaker for this behavior.
  • The underlying principle is that "the only way out is through," emphasizing direct action over complex avoidance tactics.
  • This approach is codified in EbT's 'Have You Tried Solving The Problem?' Rule, which helps cut through unnecessary complexity.

The EbT's 'Have You Tried Solving The Problem?' Rule

- Identify Tendency to Over-architect: I have a tendency to do this where I will uh overarchitect a solution to something. And I will convince myself that like this elaborate way will be the solution instead of the the obvious.

- The Question: Have you tried solving the problem?

- The Principle: The only way out is through.

When This Works (and When It Doesn't)

This rule shines when you find yourself stuck in a loop of planning, designing, or researching ever-more-complex solutions for what might be a straightforward issue. It applies perfectly when you're “trying to find a way around” a problem – perhaps building a new software feature when a manual process could validate the need, or crafting a detailed marketing funnel before you've even made a few direct sales calls. It acts as a mental circuit breaker, forcing you to consider the most direct path forward, often involving a less glamorous, more immediate action.

However, this rule isn't a license to never architect. It breaks down when genuine complexity is required upfront for long-term stability or scalability. If you're building foundational infrastructure, designing a system that requires strict security protocols, or tackling a deeply intertwined technical challenge, extensive planning and architecture are not "over-architecting" – they're essential. The rule is for avoiding unnecessary complexity, not for skipping necessary strategic design work that prevents catastrophic future problems.

What to Do With This

This week, pick one problem you’ve been circling at your startup – something you've considered building a new tool for, or implementing a multi-step process to solve. Before you write another line of code or create another Gantt chart, apply EbT's Rule.

First, Identify Tendency to Over-architect: Are you, like Sam Parr, convincing yourself that an elaborate software integration is the only way to track sales leads, when a shared spreadsheet might actually serve your current team size and lead volume just fine? Or perhaps you're designing a complex customer onboarding flow when 80% of your current users just need a simple welcome email and a clear next step. Be honest about your desire to build something fancy over something functional.

Next, ask The Question: "Have you tried solving the problem?" For the sales lead example, the problem isn't "lack of a CRM." It's “leads falling through the cracks.” Have you simply tried calling every lead the day they come in? Have you tried setting up a simple email reminder for follow-ups? For customer onboarding, the problem isn't “lack of an interactive tour.” It's "users getting stuck." Have you just tried talking to five new users and observing where they actually struggle?

Finally, internalize The Principle: "The only way out is through." Your "through" might be a 15-minute daily check-in on new leads with your team, or a quick, personalized Loom video showing a user how to complete their first action. These are direct, less glamorous solutions that prove the real problem and its simplest fix before you commit to building out a complex, potentially unnecessary system.