Assume You’re Wrong

I was at PayScale for a little over 7. I’ve had some really incredible mentors along the way, and after several years, I’ve synthesized a lot of my learning into one simple sentence: Assume You’re Wrong.

I started taking this philosophy after designing several A/B tests and having all of our awesome designs and ideas ultimately fail when put in front of users. For the next test, my boss at the time, Doug, said: “Adam, what do we learn when this test fails?” I remember thinking: “oh sh*t. This is such an obvious thing to be asking myself, but I haven’t been.” It was one of my rare moments of introspection that help transform me: I need to assume that I’ve gotten at least one thing wrong, and that that was OK, but I needed to understand that a flaw existed.

One of the most difficult problems as a program or product manager is that you become attached to your solution to a problem, and forget that a flaw exists in your plan. Then, when someone criticizes that solution, you become defensive. If you take the approach that what you’ve come up with just one of the many possible solutions to that problem and that another solution to that problem may be better, you’re leaving yourself open to improving your product.

And, even before you’re talking or showing a potential solution to others, you can use this position to help you be critical of your own work. When you assume that there is a flaw in your logic or solution, you’ll be looking for one, and odds are that you’ll find one.

Feedback can come from anywhere. Don’t discount it even if it came from source you don’t like. Assume they know something, and that you may be wrong.