For many of us, overthinking is a bigger threat to our success than failure.

"If you're not iterating really, really quickly, you're building a high-quality product for the universe of your brain, not a high-quality product for the universe of reality." —Shir Yehoshua

The above quote is about product development, but it encapsulates the Overthinker's Paradox more generally. This concept applies whether you're trying to build a better you, a better product, or a better life.

An overthinker who is trying to improve anything, including themselves, exhaustively thinks about how they could do that. However, without rapid experiments and iterating based on the results, it's all theoretical. What the person could achieve is limited by their imagination. The reality of what they could actually achieve might be much more extensive, or completely different.

Here's how you can defeat the overthinker's paradox:

1. Master the 30-Minute MVP

To avoid over-complicating projects, aim to create your first version, your minimum viable product, in 30 minutes. Your MVP should be the simplest version of your product that’s actually useful, and that you or your customers (or colleagues/students etc.) would want to use.

A “product” could be a tool for your personal use, like a template for one of your repeated tasks.

If there simply isn’t an MVP you can complete in 30 minutes for a particular project, there will often be an MVP you can complete in 2 hours. When we shrink a project down to something we can complete in 30 minutes or 2 hours, it works with the constraints of our ability to focus. This often allows us to complete it in a single session of work.

2. Celebrate Work You Delete to Help Overcome the Sunk Costs Bias

The sunk costs bias—our reluctance to change our strategy when we've already invested effort or money—is part of why overthinkers are reluctant to experiment.

Here's an example I encountered today in my work as a writer. I had written a blog post that was too long and too complicated. It had languished in my drafts folder for weeks. I knew it wasn't good writing and felt demoralized by it. I had put in too much effort and that had made the piece worse. I decided to chop down the article from five points to three, and dramatically simplify each point. Then, I celebrated having deleted over half of the work I'd previously done.

The analogy in software design is deleting lines of code. In product development, it's abandoning features or entire products that you create, but that don't work when you test them. You celebrate learning what you tried didn't work, so you can move on to better things.

Don't let sunk costs keep you stuck.

3. Create a Process to Share, or at Least Log, Failed Experiments and Work You Delete

Work teams should present failed experiments and deleted work in shared channels. We can learn from sharing our failed experiments and having deleted work, and it overcomes productivity shame.

Develop a parallel method in your personal life. For example, keep a running log of what you deleted or abandoned after testing, as part of celebrating learning and moving on.

4. Label "Edge Cases" as Such

"Edge cases" is an engineering and design term that means rare or extreme situations that test the limits of how something is designed to work. For instance, a user trying to order 1,000 items in a shopping app meant for small purchases is an edge case.

We can borrow the term to simplify our thinking. Overthinkers often become consumed by pondering edge cases before it's necessary.

When you're overthinking about an edge case, label it as such. That way you can remind yourself that the edge case may not be the most important thing to prepare for, especially at different stages of building whatever it is you're trying to build or develop. As previously mentioned, this includes when what you're attempting to build is a better you, or a better life.

5. Feedback on What Isn’t Working Is a Good Sign

Recognize that getting a lot of feedback on what isn't working during an experiment can be a good sign.

Let's say you make a tool for yourself. You use it and discover there is a lot wrong with your MVP. It needs a lot of fixing. When you experiment and get a deluge of feedback on what's not working, it means someone is using what you created.

If you don't hear anything, it could mean it works great or that there is little interest. If you get a lot of feedback, it means there is interest.

By building quick prototypes and learning from their failures, you get grounded in reality and find problems more efficiently.

6. Recognize You Can Learn to Iterate Quickly, Without Buying Into Other Aspects of Hustle Culture

I'm a fan of iterating quickly, but not of hustle culture generally. I've written extensively about the benefits of "wasting time," utilizing the power of the unfocused mind, and not limiting yourself only to what you can do consistently. For example, the unfocused mind has strengths that the focused mind does not, and we can achieve greater productivity through learning how to get things done in unfocused states, not merely obsessing about increasing our focused time and ability to focus. Likewise, if you limit yourself only to what you can do consistently, it limits you. Productivity is naturally spiky. It's part of being human.

You don't have to adopt hustle culture unilaterally to benefit from an attitude of running fast and fun experiments. It's easy to associate iterating quickly with an old Facebook mantra, "move fast and break things." You don't have to adopt hustle culture as a bundle. If you iterate fast, you can do it with the purpose to move fast and fix things. Create an internal work culture that matches your values.

Learn from Doing, Not Thinking

Overthinking often traps us in the realm of possibilities and potential edge cases that might never eventuate, but success comes from taking action and learning from reality. By learning to make slim prototypes first, experimenting quickly, and embracing failure as a step forward, we can overcome the Overthinker’s Paradox and achieve more than we imagined.