The Product Manager’s Guide to Combating Perfectionism

At Earnest, we look for product mangers who exhibit high levels of analytical, technical, and strategic thinking. It is no coincidence that these traits are commonly found in individuals with backgrounds in engineering or other quantitative fields. And it should come as no surprise that these individuals who spent a lot of time solving problems with singularly correct answers are often perfectionists.

Being a practiced perfectionist may have gotten you full marks in school, but it will only cause you a series of compounding headaches as a product manager. If you hand your perfectionism the reins, here’s what might happen.

Requirement gathering ad infinitum

You start work on a project with little context and need to gain it quickly. You spend the first couple of days asking the big picture questions. Great, context achieved. Then you spend the next 25 working days (which may be more or less than a calendar month depending on what other traits you possess) digging into every nook and cranny excavating answers to questions that you’re no longer sure matter to the problem you’re trying to solve. But your perfectionism tells you, “This just might be useful”, so you research and write it down.

Overanalyzing decisions big and small

Now that you’ve assembled a tome of information to work with, you’re ready to carve out that product spec. But first, you have to make some decisions. Because of all your information gathering, you are very well informed of the solution space. Instead of weighing two or three options, you consider ten. As a perfectionist, you struggle with this task especially because you suffer from analysis paralysis. You find yourself fixated on a single seemingly unsolvable problem in a queue filled with unsolved questions. For some reason, routine choices such as selecting work priorities for the day or simply naming your feature soon prove to be challenging tasks.

Suffering from scope blowup

You’ve finally made all your decisions. But something’s not right. It dawns on you that what you’ve committed is not scope creep, but total scope blowup. Instead of coming up with a spec for an internal tool MVP that consisted of a couple of form field inputs and a simple save and delete mechanism, you’ve penned a plan to create the last tool your stakeholders will ever need, ever. The proposed tool is actually a suite of tools with animation requirements, versioning, and full automation to boot. It’s also going to take an extra nine months and five engineers you don’t have. You’re not sure how this could’ve happened.

The sequence of events leading to scope blow-up is an easy crime for a perfectionist to commit. As a product manager, you make decisions all. day. long. Because you are constantly making difficult trade-offs, your decision making ability can deteriorate as the day progresses, a phenomena known as decision fatigue.

This can mean that you avoid making tough calls in the evening, instead defaulting to your status quo. You may default to no, but let’s be honest, it’s much easier for most people to say yes. So you default yes to your stakeholders’ requests. Yes to this additional feature. Yes to dealing with additional situations. Yes to scope blow-up.

Anti-Perfectionism Combat Techniques

Any of these situations sound familiar? Because only you can prevent scope blow-up. Here are some tips for keeping your perfectionist tendencies in check.

Done is better than perfect

It doesn’t matter how lovely your feature or product is if no one ever gets to use it. If you do manage to eventually launch it, there’s a chance that what’s perfect to you might not be perfect or even any good for your users.

Perfection is a moving target.

To avoid committing to this route with no recourse. Instead, consider launching in stages. This allows you time to get feedback from your users and iterate to get them what they need.

This applies to individual problems as well. Instead of fixating on one issue, allow yourself to explore where that path leads. Addressing connected problems and tweaking answers to previous ones may allow you to come up with a better overall solution.

Make time-constrained checkpoints

To avoid needing a legal binder to organize all of your requirements, force yourself to deadlines. Your project will have a final deadline. Work backward from there. Your timeline might have three intermediate deadlines: when to finish gathering requirements, designing specs, and complete engineering. You can then create smaller deadlines.

For example, suppose your stakeholders are Legal and Marketing. When gathering requirements, set deadlines for when you have your first meetings and final meetings with each team. With each project you work on, you can then look back on which deadlines you hit and which ones you missed. If you find yourself missing deadlines for spec’ing, you can either allow yourself more time in the future for that step or learn to filter decisions.

Filter decisions

You might have read that you should make the most important decisions first. Those researchers are right. I’ve found that the decisions I waffle over in the previous evening I can make decisively the next morning. But how do you decide what is an important decision and what isn’t?

One way to decide is to map your product specifications against the list of core problems that they need to solve. It is easy to frame your decisions against this list — it’s an important decision if you are addressing core problems. In your first few months as a product manager, it may be difficult for you to judge whether a problem is core or not. Is it important to solve this problem now? What other problems might we be able to address instead? What are the ramifications if we never work on it?

One of the essential skills you develop on the job is the ability to intuit the approximate costs and benefits of resolving different problems within the context of your time, team, and company.

For example, at Earnest, one of our early concerns was deciding how to capture an applicant’s income. Some incumbent lending companies were taking reported income at face-value, and we could have made the same choice. However, we made the decision that the additional benefit of verifying self-reported income outweighed the cost, both operationally and technically. Thus, we added veracity as a core concern in addition to reportability and auditability. We built the feature so that we could capture reported income, store evidence, verify that the evidence and reported values matched, and report all of this later on.

Now what should you do with those small decisions? Eliminate them or do them at the end of the day. Use your ability to understand costs and benefits to eliminate decisions where the tradeoff differences are low. Plan out your priorities for the following day at night, so you can hit the ground running. Avoid deciding which meetings to attend by installing extensions that automatically reject meeting invites that conflict with existing ones.

Find what works for you. I’ve only written about a fraction of the things I’ve tried to be more effective as a product manager and combat perfectionism. These are the principles that have worked best for me. If you find something else that is effective, I’d love to hear about it. If you happen to not be a perfectionist, we’re hiring too.

Kevin is a product manager at Earnest and a recovering perfectionist. Prior to Earnest, he managed a $16mm investment fund and earned a BA in Economics at Stanford University.