It’s only slowing you down — here’s how to handle it

Saar Berkovich
Jul 28 · 5 min read
Photo by Ksenia Makagonova on Unsplash

Perfectionism is a controversial trait.

While it is associated with professionalism, drive, and attention to detail, perfectionists are known to suffer from work-related stress, overanalysis, and fatigue, up to the point where many of them want to break free.

In an early-stage startup environment where agility and constant iteration are key, perfectionism can be a real hindrance. The notion of wanting your work to be perfect means spending more effort (and time) than necessary, leading to broken deadlines, late delivery, and delayed learning. When burn rates are involved, moving too slow can be detrimental to a startup’s survival.

As a recovering perfectionist myself (or so I want to believe), I am writing this post to share lessons learned from starting a company in my friend’s living room, raising VC money, and launching a mobile app that amassed half a million downloads (to date).

Breaking free from the shackles of perfectionism is an ambiguous decision and a true challenge, my goal in writing this is, hence, helping others learn to work around their perfectionism — not to quit it.


Set Lean Scopes

Never ship a full product in a single release. Instead, break it up by features, releasing one feature at a time. This will allow you to put more time and focus into single features while still delivering them to users, and gathering feedback which is essential to advance.

One thing you can try is to plan to build and release your features in descending order of importance. After each release, gather feedback, and should priorities change, alter your build order (in other words — Build-Measure-Learn). The metrics used to measure “importance” here vary on a situational basis, but a few ideas for important features are ones validate hypotheses, generate revenue, or increase growth.

Do not confuse a complete product with a perfect product. A product that is being used by users to solve a singular problem is a better product than a complete product that nobody uses at all. The desire to release a complete product could lead to weeks and months of work on a product that people may not want to use at all.

Use the Market to Your Advantage

It doesn’t matter how competent of a web developer you are; creating a pretty, bug-free, secure landing page that logs signup to a database will take you longer than creating a landing page with Launchrock (or any other landing page builder) that will achieve the same effect.

Products that exist for years will always be more polished than what you or your team can build in a couple of days. Use them when you want to deliver ad hoc solutions without compromising on quality.

You may be concerned that a VC or technical due diligence analyst will question your technical prowess after having noticed you built your prototype in WordPress. This is an unlikely situation, but should it come to that, you can always explain that you wanted to launch as quickly as possible in order to gather feedback. If they still don’t get it, you don’t want them to sit on your board anyway.

Refrain From Overthinking

Perfectionists tend to overanalyze matters in the product development cycle, resulting in procrastination and valuable time wasted.

If you find yourself constantly rethinking interactions or flows, remember that as much as you streamline those, some users are never going to get it (instead, try to make your flows as simple as possible to begin with).

If you long for the perfect launch, know that unless you have a significant backing, your launch is probably not going to reach a lot of people. This is a good thing — it means that you could make multiple launches, giving you time to iterate your product if it wasn’t good enough the first time around. In case you do have just the one shot, one opportunity, Neil Young would argue that it’s better to burn out than to fade away (and he would know).

It could be hard to catch yourself in the act of overthinking. A few signs to look out for: when you find yourself having drawn-out meetings about seemingly mundane issues, and when you constantly delay releases. The way to deal with those is to timebox meetings and to set deadlines respectively. If there’s something crucial missing, it will probably come up before you release, anyway.

In general, overthinking is the bane of smart people, and it’s much healthier to avoid it altogether (easier said than done).

Refrain From Over-Engineering

This is the technical version of the last point. Perfect code doesn’t need to cater to all foreseeable and unforeseeable cases — it needs to cater to one use case reliably. There is little point to forcing polymorphism upon every class in your code when you’re not sure you’re ever going to write a subclass to take advantage of it (and before “OOP is dead” comments — this is just an example, you guys).

Premature abstraction is but one way a perfectionist engineer may confuse providing a perfect solution with providing an excessive solution. Another can appear in the form of architecture design. Building for scale is important, and refactoring is not fun, but worse than refactoring is discovering that this full-blown library you wrote will not see use, as you just decided to pivot.

Don’t build for tomorrow, build for today with tomorrow in mind.


Find the Right Balance

So, you’ve read the above, you’re feeling inspired and eager, you’re sick of delaying your launch, and you want to release now. Be aware that there is such a thing as launching too soon, and that the desire to get to launch quickly does not excuse launching a bad product.

All-or-nothing thinking is another thing perfectionists deal with. Before you do any product-related task, ask yourself: what impact is the task going to have? Weigh that against the effort it will take. For instance, taking time to ensure pixel-perfect alignment on your UI is probably not worth it, but launching with a badly aligned UI will undoubtedly hurt your UX. Similarly, fixing a crash that affects 10% of users is critical, but fixing a minor bug that affects a handful of users may not be.

Conclusion

Building a startup is hard work, and building a perfect startup is impossible work. You are not compromising your professional integrity if your early releases don’t quite match your high work standards, and you shouldn’t feel bad about it.

Oh, and that thing you’ve been working on for the past few months — if it works, you should probably release it and link it in the comment for all of us to see!

Better Marketing

Advice & case studies

Thanks to Michael Ostrovsky

Saar Berkovich

Written by

Software Engineer, fascinated by all things technology; passionate about video games, music, science, traveling, and building stuff.

Better Marketing

Advice & case studies

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade