The right amount of perfect

Everybody knows that perfect is the enemy of good, but it’s one of those tenets that’s easy to say and hard to live by. When you’re working on a creative project, there’s almost always something you wanted to do better, or some little detail that didn’t quite live up to your standards. That can be tough to accept.

This is why thoughtful project scoping and timeboxing is so important: if you don’t have a structured process and an end date for your work, you’ll be more likely to wander out into the perfectionist weeds. The farther out you get, the more time you’ve spent—mostly for diminishing returns.

At Basecamp, we protect ourselves against these problems by carefully scoping our projects and scheduling them in 6-week increments. This forces us to keep a regular cadence of shipping new things. Along the way, we have to make tough calls, and give up on always being perfect.

But even with that system in place, there’s still another tricky aspect of perfectionism: what perfect means for one project doesn’t necessarily apply in the same way to another. You have to redefine your standards every time.

Here’s an example.


Right now we’re working on some new stuff. It’s in the very early stages, so our level of tolerance for imperfections can— and should—be very high. We’re in the figuring things out phase, NOT the production-quality product phase.

So what’s the problem?

We’re extremely good at making production-quality software! Maybe a little too good. Our natural temptation is to apply our usual rigorous development practices to the new stuff we’re exploring.

You don’t need so much rigor, early on. You need only the right amount of perfect. What that means depends entirely on your situation.

When you’re inventing something from scratch…

…the right amount of perfect is an ugly sketch with a Sharpie marker. Or some hardly-formed daydreams, haphazardly pecked into a notes app.

Perfect inventing

When you’re making a prototype of an idea…

…the right amount of perfect is a barely-working demo. Can you show the idea to someone, well enough to demonstrate how it should work—even if it’s stitched together with duct tape and popsicle sticks? Perfect.

When you’re building something new…

…and Getting Real with it, the right amount of perfect is “basically functional.” You need to use this new thing to learn and keep iterating, so it has to work fundamentally. But it certainly doesn’t have to be polished. It can be clunky. It can have lots of bugs. It can have unfinished parts. At this stage, finishing everything to a high level of perfection is a waste of time, because you might well throw out half the work along the way. You need just enough perfect to be able to make judgements and improvements, but no more than that.

Finally, when you’re certain your idea has legs…

…and you’re committing to going for it, that’s when you can swing back around and make it fully considered, polished, and complete. This is the moment for production-quality rigor. Full speed ahead. Get those high standards back in action!


Transitioning between those phases is tumultuous, but it helps to clearly define which phase of a project you’re in, and what the expectations are for what you’re making. (You can do that formally or informally.)

My trick is to repeatedly ask myself, “How fancy does this need to be, for right now?” The answer is usually: NOT SO FANCY. This is a helpful gut check that helps you pull back from overdoing something.

Consider full perfection a luxury you can indulge when you have nothing else more significant to worry about. For most teams, and most projects, that happens exactly 0% of the time. 😅

4 thoughts on “The right amount of perfect

  1. The earlier you can validate that what you are making is doing the job the user is hiring for, the more fun the higher-fidelity work becomes!

    I have also found that by showing a user a comparable tool that already exists is helpful too. You can see where their friction is with the current offerings/layouts to get them to open up on something that is more magical.

    What is the most MacGyver move you have pulled with a prototype at Basecamp?

  2. I go through this process when writing drafts for my weblog. Sometimes, I get caught up in editing paragraphs to make it “high fidelity” that I lose out on the core idea, but most times I give myself permission to be truly divergent (or perfect enough in your parlance). I wrote about this a while back at https://dazne.net/dc/.

    This is also a good reminder that one has to focus on doing the right things before you work on making them better.

  3. This is a great approach if the business is willing to and understands the difference between the phases. Have seen to many POCs go live then not get touched because not enough people know how it works and there are no tests. These are usually business that do not understand the value of learn and repeat, they just do and move on.

  4. Thank you for such a Lovely Post Jonas. I too often find myself juggling in between tasks and then end up doing nothing of substance.

    Timeboxing and other such techniques of Concentrating your focus on a Single task at a time could really of great value. I Wrote about timeboxing somewhere here.

Comments are closed.

Basecamp running on a laptop

Hey, have you tried Basecamp lately?

Used an earlier version, but moved on? Heard of it, but never signed up? Today's Basecamp will surprise you! It's all-new, thoroughly modern, and unlike anything else. Now you can ditch Slack, Asana, Trello, Jira, Dropbox, or some other messy jumble of products. Simplify and centralize around Basecamp instead. It's all you need for project management and internal communication. Try it free today and see what you've been missing.