Back to Blog
Confessions of a Recovering Perfectionist

Confessions of a Recovering Perfectionist

MarkMark

I'm a recovering perfectionist.

There, I said it. And if you're reading this, you might be one too.

That struggle when you are almost done, but don't want to show it until it is perfect? So you spend days fine tuning things, just in case.

That's the perfectionist trap.

As someone who cares deeply about quality, I've spent a lot of time in this trap. Way more than I would care to actually sum up. I've also learned that it's not just about quality, but about the value of the work. About realistically assessing the offering and its potential improvements against the law of diminishing returns. About making sure that the right things work great and maybe overcoming that deeply uncomfortable feeling of not having every little detail perfect. That maybe shipping at 85% of perfect is a good thing.

A friend once shared with me the saying that perfection is the enemy of good. And I think that's true. I've tried to embrace that.

My Philosophy: Balancing Effort and Value

I am sure you are all very familiar with the Pareto principle. What I think is more interesting is when you let go of that last few percentages, shift to the next problem and allow the aggregate value to compound over time.

Let me show you what I mean with this chart:

Compounding Pareto Principle

This chart compares two approaches to value creation:

The "Single Perfect Feature" approach (orange line) shows diminishing returns as you try to perfect one thing. You get steep initial gains, but the curve flattens dramatically in the last 20%. You're putting in 80% of the effort for maybe 20% more value.

The "Compounding Pareto Principle" approach (stacked green areas) shows how delivering multiple features sequentially can lead to much higher overall value. Each feature reaches a "good enough" state, then you move on to the next, allowing value to compound over time.

This is why perfectionism costs you — while you're squeezing the last 15%, you could have built something else that adds more total value.

I also want to flag that stopping at 85% of perfect isn't about lowering standards. It's about maximizing value to clients by focusing effort where it matters most, and where I have the most visibility about concrete value I can provide now.

(And I know I can always go back and finesse the last 10-15% later - preferably when I have more feedback and a better understanding of the problem)

My Perfectionist Confessions

Let me share some embarrassing moments where I strayed too far into perfectionism:

The Dashboard That Could Have Waited

I spent weeks building a popup dashboard with the ability to de-sync from the main taskpane for testing hypotheses without disturbing the main configuration. It's a great feature—users can now have a full-screen dashboard that operates independently from the taskpane - really enabling them to dig into the details and understand their options and risks. But here's the thing: I could have probably shipped Bear Decisions two months earlier without it.

Other examples where I might have over-invested time include:

  • Ability to export all the data directly into a table ready for putting into a pivot table or PowerBI
  • Ability to create +/- 20% type alternative cases with a single click (if you don't have a deterministic alternative case pre-defined)

These are all valuable features. But were they worth delaying the entire product? Probably not.

The Feature Creep Chronicles

I love solving problems. Sometimes that involves building features. There's something deeply satisfying about solving a problem elegantly. But I've learned that not every elegant solution needs to be built right now.

I could have spent another month adding:

  • Advanced filtering options
  • Automated reporting templates
  • Monte Carlo analysis processes

But would any of those features have made the core product more useful for the first 100 users? Unlikely.

Problem Selection Remains the Most Important Thing

I’ve managed complex applications before. I was the one person who knew what every button did… and also the one who knew that most users only touched 10–20% of them. We’d slowly fallen into the “more” trap — adding features because we could, not because they truly mattered.

With Bear Decisions, I’m trying to do it differently. My goal is to make it as usable and comprehensible as possible. Lots of small, intentional design choices that make it work well — not just piling on buttons and options until “more” turns into “confusing” and eventually “ignored.”

AI makes this a double-edged sword. On one hand, I can now build (some) ideas in 10–30 minutes that used to take days. On the other hand, it’s never been easier to fall into the “just one more feature” spiral. Faster isn’t the same as better. The real challenge hasn’t changed: pick the right problems to solve, then solve them the right way.

That’s why problem selection matters most. In the old world, you’d probably say no to 95% of ideas. With AI, maybe you can say yes to 10% instead of 5% — but you’ll also have way more ideas than before. Which means you still have to triage, rank, and ruthlessly prioritize.

From Software Development to FP&A: The Same Philosophy

The same thing happens in FP&A and planning workflows. It’s easy to believe that adding more data, more factors, or more decimal places will make the model better.

I’ve seen teams spend months building the “ultimate” model — every variable, every dependency, every edge case accounted for — only to discover that when the decision moment came, the model was too slow, too complex, and too hard to update. All that precision and complexity didn’t help; it just delayed the answer.

The lesson’s the same: whether it’s software or financial models, the goal isn’t to build more, it’s to build something useful, timely, and actionable.

My Development Choices

So here's what I've learned about being a recovering perfectionist in software development:

1. Ship Early, Iterate Often

The best feedback comes from real users using real software. Not from your imagination about what users might want.

2. The 85% Rule

If you can get to 85% of what you envision in a reasonable amount of time, ship it. The remaining 15% can come in version 2.0.

3. Question Every Feature

Before building anything, ask: "Would this feature make the product more useful for the next 100 users?" If the answer is no, it can wait.

4. Focus on Core Value

What's the one thing your product does better than anything else? Focus there. Everything else is secondary.

5. Embrace Appropriate Precision

Not every problem needs perfect precision. Sometimes "good enough" is exactly what you need to make better decisions.

What This Means for Bear Decisions

I'm building Bear Decisions with this philosophy in mind. It's not about creating the most complex scenario analysis tool possible. It's about creating a tool that helps you analyze more cases and get greater insight because it isn't about precision—it's about appropriate, directionally correct decisions, with good expectations about likely outcomes.

The goal is to help you make better decisions under uncertainty by:

  • Analyzing more scenarios with less effort
  • Understanding the range of possible outcomes for each of the options
  • Identifying the critical risks and their potential mitigations
  • Making decisions that are robust across different scenarios

And I'm leaning on you—the users—to tell me what matters most. User research will help me delve into the elements that make the biggest difference, not just the ones that are technically interesting to build.

The Bottom Line

Being a recovering perfectionist isn't about lowering your standards. It's about being strategic about where you apply them.

It's about recognizing that the best tools aren't the ones with the most features—they're the ones that solve the right problems for the right people at the right time, with appropriate precision.

And sometimes, that means focusing on directionally correct decisions rather than perfect precision.


Are you a recovering perfectionist too? I'd love to hear your stories about balancing effort and value in your work. How do you decide when 'good enough' is good enough? Drop me a line at mark@babybearanalytics.com or connect with me on LinkedIn. I read every message.

And if you're ready to see what a recovering perfectionist can build when they focus on the right problems with appropriate precision, join our waitlist for early access to Bear Decisions.